Re: [RFC PATCH] block: Change default IO scheduler to deadlineexcept SATA

From: Mike Snitzer
Date: Tue Apr 10 2012 - 16:12:35 EST


On Tue, Apr 10 2012 at 3:55pm -0400,
Jens Axboe <axboe@xxxxxxxxx> wrote:

> On 2012-04-10 21:43, Mike Snitzer wrote:
> > I'm still missing your position (other than you now wanting to make it
> > a userspace concern).
> >
> > Put differently: why should CFQ still be the default?
> >
> > It is pretty widely held that deadline is the more sane default
> > (multiple distros are now using it, deadline is default for guests,
> > etc). CFQ has become more niche. The Linux default really should
> > reflect this.
> >
> > The only case where defaulting to CFQ seems to make sense is
> > rotational SATA (and USB).
>
> That's the precisely the reason it should still be the default. The
> default settings should reflect a good user experience out of the box.
> Most desktop machines are still using SATA drives. And even those that
> made the leap to SSD, lots of those are still pretty sucky at high queue
> depths or without read/write separation. So I'm quite sure the default
> still makes a lot of sense.

I agree that a default of CFQ still makes sense for SATA and USB.

But why can't there be multiple defaults?

default: deadline
SATA and USB default: cfq

> Punt tuning to the server side. If you absolutely want the best
> performance out of your _particular_ workload, you are expecting and
> required to tune things anyway. Not just the IO scheduler, but in
> general. You can't make the same requirements for the desktop.

Just because server admins are more used to tuning doesn't mean all
server admins do it -- especially not on first evaluation.

> As to kernel vs user, I just see little reason for doing it in the
> kernel if we can put that policy in user space.

There are distro packages that are shipped to control such knobs,
e.g. tuned.

They don't help _at all_ if the user doesn't know about them. Knob
tuning is tedious on multiple levels. Much like this thread ;)
--
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/