From: Jens Axboe <axboe@kernel.dk>
To: Paolo Valente <paolo.valente@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
linux-block <linux-block@vger.kernel.org>,
linux-mmc <linux-mmc@vger.kernel.org>,
linux-mtd@lists.infradead.org, Pavel Machek <pavel@ucw.cz>,
Ulf Hansson <ulf.hansson@linaro.org>,
Richard Weinberger <richard@nod.at>,
Adrian Hunter <adrian.hunter@intel.com>,
Bart Van Assche <bvanassche@acm.org>, Jan Kara <jack@suse.cz>,
Artem Bityutskiy <dedekind1@gmail.com>,
Christoph Hellwig <hch@infradead.org>,
Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
Mark Brown <broonie@kernel.org>,
Damien Le Moal <Damien.LeMoal@wdc.com>,
Johannes Thumshirn <jthumshirn@suse.de>,
Oleksandr Natalenko <oleksandr@natalenko.name>,
Jonathan Corbet <corbet@lwn.net>
Subject: Re: [PATCH v2] block: BFQ default for single queue devices
Date: Mon, 22 Oct 2018 02:21:47 -0600 [thread overview]
Message-ID: <fa57d440-dff1-e260-c8c9-6d4bf04221a8@kernel.dk> (raw)
In-Reply-To: <E2DDE0B9-F693-4EF3-B90C-C57F787B4DB3@linaro.org>
On 10/19/18 4:59 AM, Paolo Valente wrote:
>
>
>> Il giorno 15 ott 2018, alle ore 20:26, Paolo Valente <paolo.valente@linaro.org> ha scritto:
>>
>> ...
>>> This kind of policy does not belong in the kernel, at least
>>> not in the current form. If we had some sort of "enable best
>>> options for a desktop" then it could fall under that umbrella.
>>>
>>
>> I don't think bfq can be considered a scheduler for only desktops any
>> longer.
>>
>
> Hi Jens,
> this reply of mine went on bugging me, until I understood my mistake.
>
> The fact that I consider bfq good also for servers *does not* imply
> that having bfq in desktops is to be refused.
>
> As for the option that you are hinting at, I also acknowledge that it
> would be trivial for an admin/developer to know whether a given kernel
> is meant for a desktop/personal system, while it is more difficult to
> choose explicitly among the various I/O schedulers available.
>
> So, I apologize for my shortsighted, initial reply, and ask you if can
> elaborate a little more on this. I'm willing to help, if I can.
I think I've written about this multiple times now, but for me it
really just boils down to sane default, and policy in the kernel.
BFQ is very complicated, about 10K lines of code. I'm not comfortable
making that the default right now - as I've mentioned in other
replies, I think something like that should be driven by the distros
as they will ultimately be the ones that usually get complaints
about behavioral changes that impact performance adversely. This isn't
just about running some benchmarks and calling it a day.
Maybe some day we can make it the default on mq for single queue
devices, but I just don't think we are there yet in terms of
coverage.
While I don't work for a distro anymore, I do have my hands dirty
with a fairly substantial deployment at work. There we run mq-deadline
on single queue devices, and kyber on multiqueue capable devices.
--
Jens Axboe
next prev parent reply other threads:[~2018-10-22 8:21 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-15 14:10 [PATCH v2] block: BFQ default for single queue devices Linus Walleij
2018-10-15 14:22 ` Paolo Valente
2018-10-15 14:32 ` Oleksandr Natalenko
2018-10-19 8:33 ` Linus Walleij
2018-10-19 9:26 ` Oleksandr Natalenko
2018-10-15 15:02 ` Bart Van Assche
2018-10-15 18:34 ` Paolo Valente
2018-10-17 5:18 ` Paolo Valente
2018-10-16 16:14 ` Federico Motta
2018-10-16 16:26 ` Paolo Valente
2018-10-15 15:39 ` Jens Axboe
2018-10-15 18:26 ` Paolo Valente
2018-10-15 19:26 ` Jens Axboe
2018-10-15 19:44 ` Paolo Valente
2018-10-16 17:35 ` Jens Axboe
2018-10-17 10:05 ` Jan Kara
2018-10-17 14:48 ` Bart Van Assche
2018-10-17 14:59 ` Bryan Gurney
2018-10-19 8:42 ` Linus Walleij
2018-10-19 13:36 ` Bryan Gurney
2018-10-19 13:44 ` Johannes Thumshirn
2018-10-19 14:16 ` Bryan Gurney
2018-10-22 8:12 ` Jens Axboe
2018-10-17 16:01 ` Mark Brown
2018-10-17 16:29 ` Jens Axboe
2018-10-18 7:21 ` Jan Kara
2018-10-18 14:35 ` Jens Axboe
2018-10-19 8:22 ` Pavel Machek
2018-10-22 8:08 ` Jens Axboe
2018-11-02 10:40 ` Oleksandr Natalenko
2018-10-19 10:59 ` Paolo Valente
2018-10-22 8:21 ` Jens Axboe [this message]
2018-10-16 13:42 ` Ulf Hansson
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=fa57d440-dff1-e260-c8c9-6d4bf04221a8@kernel.dk \
--to=axboe@kernel.dk \
--cc=Damien.LeMoal@wdc.com \
--cc=adrian.hunter@intel.com \
--cc=broonie@kernel.org \
--cc=bvanassche@acm.org \
--cc=corbet@lwn.net \
--cc=dedekind1@gmail.com \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jthumshirn@suse.de \
--cc=linus.walleij@linaro.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=oleksandr@natalenko.name \
--cc=paolo.valente@linaro.org \
--cc=pavel@ucw.cz \
--cc=richard@nod.at \
--cc=ulf.hansson@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox