Re: [PATCH 1/1] NBD: make nbd default to deadline I/O scheduler

[Jens Axboe]

On Fri, Feb 08 2008, Paul Clements wrote:
> Andrew Morton wrote:
> >On Fri, 8 Feb 2008 09:33:41 -0800 Randy Dunlap <randy.dunlap@xxxxxxxxxx> 
> >wrote:
> >
> >>On Fri, 08 Feb 2008 11:47:42 -0500 Paul Clements wrote:
> >>
> >>>There have been numerous reports of problems with nbd and cfq. Deadline 
> >>>gives better performance for nbd, anyway, so let's use it by default.
> >
> >Please define "problems".  If it's just "slowness" then we can live with
> >that, but I'd hope that Jens is aware and that it's understood.
> >
> >It it's "hangs" or "oopses" then we panic.
> 
> The two problems I have experienced (which may already be fixed):
> 
> 1) nbd hangs with cfq on RHEL 5 (2.6.18) -- this may well have been fixed
> 
> There's a similar debian bug that has been filed as well:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=447638
> 
> 2) nbd performs about 10% better (the last time I tested) with deadline 
> vs. cfq (the overhead of cfq doesn't provide much advantage to nbd [not 
> being a real disk], and you end up going through the I/O scheduler on 
> the nbd server anyway, so it makes sense that deadline is better with nbd)
> 
> There have been posts to nbd-general mailing list about problems with 
> cfq and nbd also.

I'm fine with that, it's one of those things we'll do automatically when
we have some sort of disk profile system setup. Devices without seek
penalties should not use AS or CFQ.

Asking for a non-existing elevator is not an issue, but it may trigger
both printks and a switch to another elevator. So if you ask for
"deadline" and it's modular, you'll get cfq again if it's the default.

Your patch looks bad though, you forget to exit the old elevator. And
you don't check the return value of elevator_init().

All in all, your patch definitely needs more work before it can be
included.

-- 
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/