lkml.org 
[lkml]   [2005]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] new fifo I/O elevator that really does nothing at all
On Tue, Mar 29 2005, Bill Davidsen wrote:
> Jens Axboe wrote:
> >On Mon, Mar 28 2005, Chen, Kenneth W wrote:
> >
> >>The noop elevator is still too fat for db transaction processing
> >>workload. Since the db application already merged all blocks before
> >>sending it down, the I/O presented to the elevator are actually not
> >>merge-able anymore. Since I/O are also random, we don't want to sort
> >>them either. However the noop elevator is still doing a linear search
> >>on the entire list of requests in the queue. A noop elevator after
> >>all isn't really noop.
> >>
> >>We are proposing a true no-op elevator algorithm, no merge, no
> >>nothing. Just do first in and first out list management for the I/O
> >>request. The best name I can come up with is "FIFO". I also piggy
> >>backed the code onto noop-iosched.c. I can easily pull those code
> >>into a separate file if people object. Though, I hope Jens is OK with
> >>it.
> >
> >
> >It's not quite ok, because you don't honor the insertion point in
> >fifo_add_request. The only 'fat' part of the noop io scheduler is the
> >merge stuff, the original plan was to move that to a hash table lookup
> >instead like the other io schedulers do. So I would suggest just
> >changing noop to hash the request on the end point for back merges and
> >forget about front merges, since they are rare anyways. Hmm actually,
> >the last merge hint should catch most of the merges at almost zero cost.
>
> Making the noop faster is clearly a good thing, but some database
> software may depend on transaction order as provided by a true fifo
> process. It would be nice to have both.

Just look at the code. It does FIFO for any request that _isn't_
specified as ELEVATOR_INSERT_FRONT - which means any fs request, or any
plain pc request. There is no specific reordering going on.

Drivers expect to be able to add a request back at the head, for eg
retrying it after a QUEUE_BUSY or similar condition.

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-06 13:31    [W:0.048 / U:1.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site