Messages in this thread | | | Date | Thu, 7 Sep 2006 18:33:13 +0200 | From | Jens Axboe <> | Subject | Re: [PATCH 10/21] block: elevator selection and pinning |
| |
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@chello.nl> > > > Signed-off-by: Daniel Phillips <phillips@google.com> > > > CC: Jens Axboe <axboe@suse.de> > > > CC: Pavel Machek <pavel@ucw.cz> > > > > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |