From: Tejun Heo <tj@kernel.org>
To: Damien Le Moal <Damien.LeMoal@wdc.com>
Cc: Bart Van Assche <bvanassche@acm.org>,
Jens Axboe <axboe@kernel.dk>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [PATCH block-5.14] Revert "block/mq-deadline: Add cgroup support"
Date: Fri, 13 Aug 2021 06:29:18 -1000 [thread overview]
Message-ID: <YRad3tQaZfR8v7lb@mtj.duckdns.org> (raw)
In-Reply-To: <DM6PR04MB7081F2D0E8579489175DF363E7FA9@DM6PR04MB7081.namprd04.prod.outlook.com>
Hello, Damien.
On Fri, Aug 13, 2021 at 02:18:04AM +0000, Damien Le Moal wrote:
> Command duration limits (CDL) and Sequestered commands features are being
> drafted in SPC/SBC and ACS to give the device better hints than just a on/off
> high priority bit. I am currently prototyping these features and I am reusing
> the ioprio interface for that. Here is how this works:
And I think ioprio would be the right interface for it, combined with
some mechanism which can limit which class can take up how many of the
available command slots. Without that, it'd be really easy for anyone
to saturate the command queues and expressing priorities inside the
device won't do much.
> CDL can completely replace the existing binary on/off NCQ priority in a more
> flexible manner as the user can set different duration limits for high vs low
> priority. E.g. high priority is equivalent to a very short limit while low
> priority is equivalent to longer or no limits.
The problem with complex optional hardware features is often the
accompanying variability in terms of availability, reliability and
behavior. The track record has been pretty sad. That isn't to say this
won't be useful for anybody but it'd need careful coordination in
terms of picking hardware vendor and model and ensuring vendor
support, which kinda severely limits the usefulness.
Thanks.
--
tejun
next prev parent reply other threads:[~2021-08-13 16:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-11 17:41 [PATCH block-5.14] Revert "block/mq-deadline: Add cgroup support" Tejun Heo
2021-08-11 18:49 ` Bart Van Assche
2021-08-11 19:14 ` Tejun Heo
2021-08-11 20:22 ` Bart Van Assche
2021-08-12 17:51 ` Tejun Heo
2021-08-12 18:16 ` Bart Van Assche
2021-08-12 19:23 ` Tejun Heo
2021-08-13 2:18 ` Damien Le Moal
2021-08-13 16:29 ` Tejun Heo [this message]
2021-08-13 17:17 ` Bart Van Assche
2021-08-13 21:43 ` Tejun Heo
2021-08-13 17:15 ` Bart Van Assche
2021-08-12 18:56 ` Jens Axboe
2021-08-12 19:10 ` Tejun Heo
2021-08-11 19:48 ` Jens Axboe
2021-08-12 14:14 ` Oleksandr Natalenko
2021-08-12 15:50 ` Jens Axboe
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=YRad3tQaZfR8v7lb@mtj.duckdns.org \
--to=tj@kernel.org \
--cc=Damien.LeMoal@wdc.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=linux-block@vger.kernel.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