On 1/12/23 15:03, Niklas Cassel wrote:
From: Damien Le Moal <damien.lemoal@xxxxxxxxxxxxxxxxxx>
Introduce the IOPRIO_CLASS_DL priority class to indicate that IOs should
be executed using duration-limits targets. The duration target to apply
to a command is indicated using the priority level. Up to 8 levels are
supported, with level 0 indiating "no limit".
This priority class has effect only if the target device supports the
command duration limits feature and this feature is enabled by the user.
In BFQ and mq-deadline, all requests with this new priority class are
handled using the highest priority class RT and priority level 0.
Signed-off-by: Damien Le Moal <damien.lemoal@xxxxxxxxxxxxxxxxxx>
Signed-off-by: Niklas Cassel <niklas.cassel@xxxxxxx>
---
block/bfq-iosched.c | 10 ++++++++++
block/blk-ioprio.c | 3 +++
block/ioprio.c | 3 ++-
block/mq-deadline.c | 1 +
include/linux/ioprio.h | 2 +-
include/uapi/linux/ioprio.h | 7 +++++++
6 files changed, 24 insertions(+), 2 deletions(-)
I wonder.
_Normally_ a command timeout is only in force once the command is being
handed off to the driver. As such it doesn't apply for any scheduling
being done before that; most notably the I/O scheduler is not affected
by any command timeout.
And I was under the impression that CDL really only allows the drive to
impose a command timeout on its own.
(Pray correct me if I'm mistaken)
Hence: does CDL really impinge on the I/O scheduler? Or shouldn't we
treat CDL just like a 'normal' command timeout, only to be activated
when normal command timeout is enabled?
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
