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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
