Re: [PATCH 1/2] block/mq-deadline: disable I/O priority when prio_aging_expire is zero

On 2026/8/20 23:31, Bart Van Assche wrote:
> On 8/19/26 7:12 PM, Ye Bin wrote:
>> Since the mq-deadline scheduler introduced support for I/O priorities,
>> if a process does not have an I/O priority configured, it becomes bound
>> to the process's scheduling priority.
>
> How can this happen? The scheduling priority (sched_setparam()) and I/O
> priority (ioprio_set()) are independent as far as I know.
>
Yes, I thought so at first. However, after checking the historical records,
I found that the IO priority was set based on the task scheduling class when
the IO priority was not configured. This was introduced by the f7eda402878b
("block: Return effective IO priority from get_current_ioprio()") and
a78418e6a04c ("block: Always initialize bio IO priority on submit") commits.
>> Setting prio_aging_expire to zero does not actually turn off I/O
>> priority in mq-deadline.
>
> prio_aging_expire should not be set to zero. Feel free to submit a patch
> that disallows setting prio_aging_expire to zero.
>
Yes, setting it to 0 can cause priority inversion issues. However, I understand
that even when a relatively small value is set, priority inversion can still
occur. This is because the system first checks whether the lower-priority IO
has timed out, and if it has, it then dispatches the lower-priority IO. In
cases of high IO pressure, this can actually result in the lower-priority IO
being dispatched first. So, is it sufficient to constrain this value to zero?
Or is this value entirely up to the user to control? From the user's perspective,
a naive view would be that setting this value close to zero means not distinguishing
priorities. Indeed, our product was designed with this idea in mind, setting the
value to 0 to disable priority, but it ended up causing IO priority inversion issues.
> Thanks,
>
> Bart.
>