On 1/24/23 11:02, Niklas Cassel wrote:
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. While it is recommended to not use an ioscheduler when using the IOPRIO_CLASS_DL priority class, if using the BFQ or mq-deadline scheduler, IOPRIO_CLASS_DL is mapped to IOPRIO_CLASS_RT. The reason for this is twofold: 1) Each priority level for the IOPRIO_CLASS_DL priority class represents a duration limit descriptor (DLD) inside the device. Users can configure these limits themselves using passthrough commands, so from a block layer perspective, Linux has no idea of how each DLD is actually configured. By mapping a command to IOPRIO_CLASS_RT, the chance that a command exceeds its duration limit (because it was held too long in the scheduler) is decreased. It is still possible to use the IOPRIO_CLASS_DL priority class for "low priority" IOs by configuring a large limit in the respective DLD. 2) On ATA drives, IOPRIO_CLASS_DL commands and NCQ priority commands (IOPRIO_CLASS_RT) cannot be used together. A mix of CDL and high priority commands cannot be sent to a device. By mapping IOPRIO_CLASS_DL to IOPRIO_CLASS_RT, we ensure that a device will never receive a mix of these two incompatible priority classes.
Implementing duration limit support using the I/O priority mechanism makes it impossible to configure the I/O priority for commands that have a duration limit. Shouldn't the duration limit be independent of the I/O priority? Am I perhaps missing something?
Thanks, Bart.
