Re: [PATCH] Consolidate the request merging

Jens Axboe
2006-07-11T17:33:25Z

On Tue, Jul 11 2006, Nick Piggin wrote:
> Jens Axboe wrote:
> >Hi,
> >
> >Right now, every IO scheduler implements its own backmerging (except for
> >noop, which does no merging). That results in duplicated code for
> >essentially the same operation, which is never a good thing. This patch
> >moves the backmerging out of the io schedulers and into the elevator
> >core. We save 1.6kb of text and as a bonus get backmerging for noop as
> >well. Win-win!
> >
> >Notes:
> >
> >- I dropped the "move hot entries to front" logic. It's never been
> > proven good, and some research indicates that it's a bad idea. I doubt
> > it matters in real life, so lets just cut that away.
> >
> >- Next it might be a good idea to move the rb sorting into the elevator
> > core as well. We could save some more kernel text, but more
> > importantly it gets us one step closer to dropping deadline_rq from
> > the deadline scheduler.
>
> Seems like a good idea. I don't think this could be a downside for anyone
> except maybe Ken Chen, if it adds any overhead to the noop scheduler.
>
> BTW, IMO it is a good idea for the noop scheduler to do as much merging as
> possible, especially as it could be used for things like network block
> devices (but more merging may actually cut down on CPU and IO bandwidth
> even in the local disk case).

I agree, I actually think it's a win for noop with the cheap merging. If
anyone complains, we can always make it tweakable with a sysfs
parameter. Even for "intelligent" hardware, you have a command overhead
per request, so it makes a lot of sense to always do merging.

--
Jens Axboe