On 1/26/23 05:53, Niklas Cassel wrote:
On Thu, Jan 26, 2023 at 09:24:12AM +0900, Damien Le Moal wrote:
But again, the difficulty with this overloading is that we *cannot* implement a
solid level-based scheduling in IO schedulers because ordering the CDLs in a
meaningful way is impossible. So BFQ handling of the RT class would likely not
result in the most ideal scheduling (that would depend heavily on how the CDL
descriptors are defined on the drive). Hence my reluctance to overload the RT
class for CDL.
Well, if CDL were to reuse IOPRIO_CLASS_RT, then the user would either have to
disable the IO scheduler, so that lower classdata levels wouldn't be prioritized
over higher classdata levels, or simply use an IO scheduler that does not care
about the classdata level, e.g. mq-deadline.
How about making the information about whether or not CDL has been
enabled available to the scheduler such that the scheduler can include
that information in its decisions?
However, for CDL, things are not as simple as setting a single bit in the
command, because of all the different descriptors, so we must let the classdata
represent the device side priority level, and not the host side priority level
(as we cannot have both, and I agree with you, it is very hard define an order
between the descriptors.. e.g. should a 20 ms policy 0xf descriptor be ranked
higher or lower than a 20 ms policy 0xd descriptor?).
How about only supporting a subset of the standard such that it becomes
easy to map CDLs to host side priority levels?
If users really need the ability to use all standardized CDL features
and if there is no easy way to map CDL levels to an I/O priority, is the
I/O priority mechanism really the best basis for a user space interface
for CDLs?
Thanks,
Bart.
