On 1/24/23 13:29, Damien Le Moal wrote:
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.
Hi Damien,
What if a device that supports I/O priorities (e.g. an NVMe device that
supports configuring the SQ priority) and a device that supports command
duration limits (e.g. a SATA hard disk) are combined via the device
mapper into a single block device? Should I/O be submitted to the dm
device with one of the existing I/O priority classes (not supported by
SATA hard disks) or with I/O priority class IOPRIO_CLASS_DL (not
supported by NVMe devices)?
Shouldn't the ATA core translate the existing I/O priority levels into a
command duration limit instead of introducing a new I/O priority class
that is only supported by ATA devices?
Thanks,
Bart.
