On Tue, Feb 19 2008, Andrew Morton wrote: > On Tue, 19 Feb 2008 10:24:28 +0100 Jens Axboe <[EMAIL PROTECTED]> wrote: > > > On Tue, Feb 19 2008, Jens Axboe wrote: > > > On Mon, Feb 18 2008, Andrew Morton wrote: > > > > > + > > > > > if (e && !try_module_get(e->elevator_owner)) > > > > > e = NULL; > > > > > > > > Looks nice and simple. There might be some of the usual ordering > > > > problems > > > > when this is called during boot, maybe is-initramfs-available-yet > > > > problems, > > > > etc. But it's unlikely to make things regress from where they are now. > > > > > > Isn't request_module() and below robust enough to handle that? > > > > BTW, I've verified that it works as expected (at least after boot): > > > > carl:/sys/block/sda/queue # cat scheduler > > noop [cfq] > > carl:/sys/block/sda/queue # echo anticipatory > scheduler > > carl:/sys/block/sda/queue # dmesg > > [...] > > io scheduler anticipatory registered > > carl:/sys/block/sda/queue # cat scheduler > > noop cfq [anticipatory] > > > > So it properly loads as-iosched instead of failing, like it would have > > done before and required the user to do a modprobe as-iosched first. > > > > carl:/sys/block/sda/queue # echo foobar > scheduler > > -bash: echo: write error: Invalid argument > > carl:/sys/block/sda/queue # dmesg > > [...] > > elevator: type foobar not found > > Looks promising - let's run with it. If there _are_ startup ordering > problems then we won't be any worse off than we are now.
I've merged it for inclusion, since it tests fine here. > otoh, the system must have _some_ io scheduler installed when talking to > disks, so perhaps there won't be any such problems at all. We are guarenteed to always have noop available, since you cannot de-select that. -- 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/
