From: Mike Snitzer <snitzer@redhat.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Vivek Goyal <vgoyal@redhat.com>,
linux kernel mailing list <linux-kernel@vger.kernel.org>,
Moyer Jeff Moyer <jmoyer@redhat.com>,
linux-scsi@vger.kernel.org, kay.sievers@vrfy.org
Subject: Re: [RFC PATCH] block: Change default IO scheduler to deadline except SATA
Date: Tue, 10 Apr 2012 16:12:34 -0400 [thread overview]
Message-ID: <20120410201234.GA8265@redhat.com> (raw)
In-Reply-To: <4F849045.9070806@kernel.dk>
On Tue, Apr 10 2012 at 3:55pm -0400,
Jens Axboe <axboe@kernel.dk> 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 ;)
next prev parent reply other threads:[~2012-04-10 20:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-10 13:37 [RFC PATCH] block: Change default IO scheduler to deadline except SATA Vivek Goyal
2012-04-10 13:56 ` Jens Axboe
2012-04-10 14:21 ` Vivek Goyal
2012-04-10 15:10 ` Vivek Goyal
2012-04-10 16:13 ` Mike Snitzer
2012-04-10 17:28 ` Vivek Goyal
2012-04-10 17:40 ` Mike Snitzer
2012-04-10 18:36 ` Jens Axboe
2012-04-11 16:25 ` Martin K. Petersen
2012-04-10 18:41 ` Jens Axboe
2012-04-10 18:53 ` Vivek Goyal
2012-04-10 18:56 ` Jens Axboe
2012-04-10 19:11 ` Vivek Goyal
2012-04-10 19:19 ` Jens Axboe
2012-04-10 19:43 ` Mike Snitzer
2012-04-10 19:55 ` Jens Axboe
2012-04-10 20:12 ` Mike Snitzer [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-04-10 17:44 Xose Vazquez Perez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120410201234.GA8265@redhat.com \
--to=snitzer@redhat.com \
--cc=axboe@kernel.dk \
--cc=jmoyer@redhat.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=vgoyal@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.