Re: [PATCH 10/21] block: elevator selection and pinning

[Jens Axboe]

On Thu, Sep 07 2006, Peter Zijlstra wrote:
> On Wed, 2006-09-06 at 15:46 +0200, Jens Axboe wrote:
> > On Wed, Sep 06 2006, Peter Zijlstra wrote:
> > > Provide an block queue init function that allows to set an elevator. And a 
> > > function to pin the current elevator.
> > > 
> > > Signed-off-by: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
> > > Signed-off-by: Daniel Phillips <phillips@xxxxxxxxxx>
> > > CC: Jens Axboe <axboe@xxxxxxx>
> > > CC: Pavel Machek <pavel@xxxxxx>
> > 
> > Generally I don't think this is the right approach, as what you really
> > want to do is let the driver say "I want intelligent scheduling" or not.
> > The type of scheduler is policy that is left with the user, not the
> > driver.
> 
> True, and the only sane value here is NOOP, any other policy would not
> be a good value. With this in mind would you rather prefer a 'boolean'
> argument suggesting we use NOOP over the default scheduler?

Nope, I don't think it's the right thing to do. Either we want to pass a
type down or a profile of some sort.

For the work you are doing here, just forget about it. It's not like
it's a critical piece, just list in the README (or wherever) that noop
is a good choice and leave it at that.

> Would you agree that this hint on intelligent scheduling could be used
> to set the initial policy, the user can always override when he
> disagrees.
> 
> These network block devices like NBD, iSCSI and AoE often talk to
> virtual disks, any attempt to be smart is a waste of time.

I think you'll find the runtime overhead of them is pretty close and
hard to measure in most setups, it's things like the queue idling and
anticipation that AS/CFQ might do that will potentially decrease your io
performance. deadline and noop would be equally good choices.

So you don't want to pass down hints on "use noop", you really want to
tell the block layer that you have no seek penalty for instance. And a
range of other parameters.

-- 
Jens Axboe

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