From: Ming Lei <ming.lei@redhat.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Jens Axboe <axboe@kernel.dk>,
Damien Le Moal <damien.lemoal@wdc.com>,
Paolo Valente <paolo.valente@linaro.org>,
linux-mmc <linux-mmc@vger.kernel.org>,
linux-block <linux-block@vger.kernel.org>,
linux-mtd@lists.infradead.org,
Johannes Thumshirn <jthumshirn@suse.de>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH] block: Flag elevators suitable for single queue
Date: Mon, 1 Jun 2020 19:58:18 +0800 [thread overview]
Message-ID: <20200601115818.GB1190838@T590> (raw)
In-Reply-To: <CACRpkdYL4-Z=kaS+RfniVr=Sn-yOf+=CKMJDsn=eTK3atmGohg@mail.gmail.com>
On Mon, Jun 01, 2020 at 01:36:54PM +0200, Linus Walleij wrote:
> On Mon, Jun 1, 2020 at 9:50 AM Ming Lei <ming.lei@redhat.com> wrote:
> > On Thu, May 28, 2020 at 10:10:03AM +0200, Linus Walleij wrote:
> > > The Kyber block scheduler is not suitable for single hardware
> > > queue devices, so add a new flag for single hardware queue
> > > devices and add that to the deadline and BFQ schedulers
> > > so the Kyber scheduler will not be selected for single queue
> > > devices.
> >
> > The above may not be true for some single hw queue high performance HBA(
> > such as megasas), which can get better performance from none, so it is
> > reasonable to get better performance from kyber, see 6ce3dd6eec11 ("blk-mq:
> > issue directly if hw queue isn't busy in case of 'none'"), and the
> > following link:
> >
> > https://lore.kernel.org/linux-block/20180710010331.27479-1-ming.lei@redhat.com/
>
> I see, but isn't the case rather that none is preferred and kyber gives
> the same characteristics because it's not standing in the way
> as much?
Kyber has its own characteristic, such as fair read & write, better
IO merge. And the decision on scheduler isn't only related with device,
but also with workloads.
>
> It looks like if we should add a special flag for these devices with
> very fast single queues so they can say "I prefer none", do you
> agree?
I am not sure if it is easy to add such flag, because it isn't only
related with HBA, but also with the attached disks.
Thanks,
Ming
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-06-01 11:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-28 8:10 [PATCH] block: Flag elevators suitable for single queue Linus Walleij
2020-05-28 8:26 ` Johannes Thumshirn
2020-05-28 11:59 ` Linus Walleij
2020-06-01 7:49 ` Ming Lei
2020-06-01 11:36 ` Linus Walleij
2020-06-01 11:58 ` Ming Lei [this message]
2020-06-01 12:53 ` Ulf Hansson
2020-06-01 23:37 ` Damien Le Moal
2020-06-01 23:45 ` Jens Axboe
2020-06-02 6:46 ` 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=20200601115818.GB1190838@T590 \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=damien.lemoal@wdc.com \
--cc=hch@lst.de \
--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=paolo.valente@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