Re: [PATCH] blk-ioprio: Introduce promote-to-rt policy

[Hou Tao <houtao@huaweicloud.com>]

Hi Jan,

On 2/10/2023 6:12 PM, Jan Kara wrote:
> On Thu 09-02-23 11:09:33, Bart Van Assche wrote:
>> On 2/9/23 00:56, Jan Kara wrote:
>>> On Wed 08-02-23 09:53:41, Bart Van Assche wrote:
>>>> The test results I shared some time ago show that IOPRIO_CLASS_NONE was the
>>>> default I/O priority two years ago (see also https://lore.kernel.org/linux-block/20210927220328.1410161-5-bvanassche@acm.org/).
>>>> The none-to-rt policy increases the priority of bio's that have not been
>>>> assigned an I/O priority to RT. Does this answer your question?
>>> Not quite. I know that historically we didn't set bio I/O priority in some
>>> paths (but we did set it in other paths such as some (but not all) direct
>>> IO implementations). But that was exactly a mess because how none-to-rt
>>> actually behaved depended on the exact details of the kernel internal IO
>>> path.  So my question is: Was none-to-rt actually just a misnomer and the
>>> intended behavior was "always override to RT"? Or what was exactly the
>>> expectation around when IO priority is not set and should be overridden?
>>>
>>> How should it interact with AIO submissions with IOCB_FLAG_IOPRIO? How
>>> should it interact with task having its IO priority modified with
>>> ioprio_set(2)? And what if task has its normal scheduling priority modified
>>> but that translates into different IO priority (which happens in
>>> __get_task_ioprio())?
>>>
>>> So I think that none-to-rt is just poorly defined and if we can just get
>>> rid of it (or redefine to promote-to-rt), that would be good. But maybe I'm
>>> missing some intended usecase...
>> Hi Jan,
>>
>> We have no plans to use the ioprio_set() system call since it only affects
>> foreground I/O and not page cache writeback.
>>
>> While Android supports io_uring, there are no plans to support libaio in the
>> Android C library (Bionic).
>>
>> Regarding __get_task_ioprio(), I haven't found any code in that function
>> that derives an I/O priority from the scheduling priority. Did I perhaps
>> overlook something?
> This condition in __get_task_ioprio():
>
>         if (IOPRIO_PRIO_CLASS(prio) == IOPRIO_CLASS_NONE)
>                 prio = IOPRIO_PRIO_VALUE(task_nice_ioclass(p),
>                                          task_nice_ioprio(p));
>
> sets task's IO priority based on scheduling priority.
>
>> Until recently "none-to-rt" meant "if no I/O priority has been assigned to a
>> task, use IOPRIO_CLASS_RT". Promoting the I/O priority to IOPRIO_CLASS_RT
>> works for us. I'm fine with changing the meaning of "none-to-rt" into
>> promoting the I/O priority class to RT. Introducing "promote-to-rt" as a
>> synonym of "none-to-rt" is also fine with me.
> OK, so it seems we are all in agreement here that "none-to-rt" behavior is
> not really needed. Hou, can you perhaps update your patches and the
> documentation to make "none-to-rt" just an alias for "promote-to-rt"?
> Thanks!
Should I keep "none-to-rt" and make it work just like "promote-to-rt" or should
I just remove "none-to-rt" and add "promote-to-rt" ? I think the latter will be
more appropriate.
>
> 								Honza