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.
-- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - 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/