On 1/25/23 04:27, Bart Van Assche wrote: > 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? I/O priority at the device level does not exist with SAS and with SATA, the ACS specifications mandates that NCQ I/O priority and CDL cannot be used mixed together. So from the device point of view, I/O priority and CDL are mutually exclusive. No issues. Now, if you are talking about the host level I/O priority scheduling done by mq-deadline and bfq, the CDL priority class maps to the RT class. They are the same, as they should. There is nothing more real-time than CDL in my opinion :) Furthermore, if we do not reuse the I/O priority interface, we will have to add another field to BIOs & requests to propagate the cdl index from user space down to the device LLD, almost exactly in the manner of I/O priorities, including all the controls with merging etc. That would be a lot of overhead to achieve the possibility of prioritized CDL commands. CDL in of itself allows the user to define "prioritized" commands by defining CDLs on the drive that are sorted in increasing time limit order, i.e. with low CDL index numbers having low limits, and higher priority within the class (as CDL index == prio level). With that, schedulers can still do the right thing as they do now, with the additional benefit that they can even be improved to base their scheduling decisions on a known time limit for the command execution. But such optimization is not implemented by this series. > > Thanks, > > Bart. > -- Damien Le Moal Western Digital Research
