On 1/13/23 20:55, Hannes Reinecke wrote: > 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) The CDL descriptors to be used for read/write commands are defined by the user and set on the drive (write log command). By default, the drive does not have any CDL descriptor set, so no limit == regular behavior (no timeout aborts). Also keep in mind that CDLs may be of the (1) "best effort" flavor, or the (2) "abort" flavor. For (2), a command missing its CDL limit will be aborted by the device (limit set by the user !). But for (1), the drive will continue executing the command even if the CDL limit is exceeded, so no timeout error. > 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? No impact on the IO scheduler, at least for now. But given that CDL is all about controlling IO latency, we would miss that goal if we have an IO scheduler that excessively delays a request with a short CDL set... The main point of this patch is to have CDL commands treated similarly to high priority commands to avoid such delays. This is also consistant with the fact that CDL and ATA NCQ priority commands are mutually exclusive features. They cannot be used together. So there we cannot have a mix of CDL and NCQ prio commands together to the same drive. -- Damien Le Moal Western Digital Research
