From: Bart Van Assche <bvanassche@acm.org>
To: Jan Kara <jack@suse.cz>
Cc: Paolo Valente <paolo.valente@linaro.org>,
Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
Jens Axboe <axboe@kernel.dk>,
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>,
Artem Bityutskiy <dedekind1@gmail.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Andreas Herrmann <aherrmann@suse.com>,
Mel Gorman <mgorman@suse.com>,
Chunyan Zhang <zhang.chunyan@linaro.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] block: BFQ default for single queue devices
Date: Fri, 5 Oct 2018 20:12:27 -0700 [thread overview]
Message-ID: <20bfa679-3131-e0af-f69d-2fbec32fbced@acm.org> (raw)
In-Reply-To: <20181005091626.GA9686@quack2.suse.cz>
On 10/5/18 2:16 AM, Jan Kara wrote:
> On Thu 04-10-18 15:42:52, Bart Van Assche wrote:
>> What I think is missing is measurement results for BFQ on a system with
>> multiple CPU sockets and against a fast storage medium. Eliminating
>> the host lock from the SCSI core yielded a significant performance
>> improvement for such storage devices. Since the BFQ scheduler locks and
>> unlocks bfqd->lock for every dispatch operation it is very likely that BFQ
>> will slow down I/O for fast storage devices, even if their driver only
>> creates a single hardware queue.
>
> Well, I'm not sure why that is missing. I don't think anyone proposed to
> default to BFQ for such setup? Neither was anyone claiming that BFQ is
> better in such situation... The proposal has been: Default to BFQ for slow
> storage, leave it to deadline-mq otherwise.
Hi Jan,
How do you define slow storage? The proposal at the start of this thread
was to make BFQ the default for all block devices that create a single
hardware queue. That includes all SATA storage since scsi-mq only
creates a single hardware queue when using the SATA protocol. The
proposal to make BFQ the default for systems with a single hard disk
probably makes sense but I am not sure that making BFQ the default for
systems equipped with one or more (SATA) SSDs is also a good idea.
Especially for multi-socket systems since BFQ reintroduces a queue-wide
lock. As you know no queue-wide locking happens during I/O in the
scsi-mq core nor in the blk-mq core.
Bart.
next prev parent reply other threads:[~2018-10-06 3:12 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-02 12:43 [PATCH] block: BFQ default for single queue devices Linus Walleij
2018-10-02 14:31 ` Jens Axboe
2018-10-02 14:45 ` Linus Walleij
2018-10-03 6:29 ` Paolo Valente
2018-10-03 6:53 ` Linus Walleij
2018-10-03 13:25 ` Jan Kara
2018-10-04 7:45 ` Johannes Thumshirn
2018-10-04 8:24 ` Andreas Herrmann
2018-10-03 7:05 ` Artem Bityutskiy
2018-10-03 7:18 ` Linus Walleij
2018-10-03 7:42 ` Damien Le Moal
2018-10-03 8:28 ` Linus Walleij
2018-10-03 8:53 ` Damien Le Moal
2018-10-03 15:53 ` Paolo Valente
2018-10-03 17:34 ` Bryan Gurney
2018-10-04 8:21 ` Linus Walleij
2018-10-04 9:56 ` Ulf Hansson
2018-10-03 12:51 ` Christoph Hellwig
2018-10-03 14:58 ` Bart Van Assche
2018-10-03 15:01 ` Christoph Hellwig
2018-10-03 15:15 ` Bart Van Assche
2018-10-05 6:24 ` Christoph Hellwig
2018-10-03 15:52 ` Paolo Valente
2018-10-03 11:49 ` Oleksandr Natalenko
2018-10-03 14:51 ` Mark Brown
2018-10-03 15:55 ` Paolo Valente
2018-10-03 16:00 ` Bart Van Assche
2018-10-03 16:04 ` Paolo Valente
2018-10-04 7:38 ` Jan Kara
2018-10-04 8:25 ` Linus Walleij
[not found] ` <CACRpkdYG2Y=rspbZ_o=H3REXTEfOcaiqEyQD4kzO=G=d63V3yA@mail.gmail.com>
2018-10-04 10:13 ` Mark Brown
2018-10-04 15:10 ` Bart Van Assche
2018-10-04 15:26 ` Mark Brown
2018-10-05 9:49 ` Pavel Machek
2018-10-03 15:54 ` Bart Van Assche
2018-10-03 16:02 ` Paolo Valente
2018-10-03 17:22 ` Paolo Valente
2018-10-04 19:25 ` Alan Cox
2018-10-04 20:09 ` Bart Van Assche
2018-10-04 20:39 ` Paolo Valente
2018-10-04 22:42 ` Bart Van Assche
2018-10-05 9:16 ` Jan Kara
2018-10-06 3:12 ` Bart Van Assche [this message]
2018-10-06 6:46 ` Paolo Valente
2018-10-06 16:20 ` Bart Van Assche
2018-10-06 16:46 ` Paolo Valente
2018-10-05 9:28 ` Paolo Valente
2018-10-05 6:24 ` Artem Bityutskiy
2018-10-04 20:19 ` Paolo Valente
2018-10-02 21:28 ` Richard Weinberger
2018-10-03 15:51 ` Paolo Valente
2018-10-05 8:04 ` Pavel Machek
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=20bfa679-3131-e0af-f69d-2fbec32fbced@acm.org \
--to=bvanassche@acm.org \
--cc=adrian.hunter@intel.com \
--cc=aherrmann@suse.com \
--cc=axboe@kernel.dk \
--cc=dedekind1@gmail.com \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=jack@suse.cz \
--cc=linus.walleij@linaro.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mgorman@suse.com \
--cc=paolo.valente@linaro.org \
--cc=pavel@ucw.cz \
--cc=richard@nod.at \
--cc=ulf.hansson@linaro.org \
--cc=zhang.chunyan@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;
as well as URLs for NNTP newsgroup(s).