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

[Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>]

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-HInyCGIudOg@public.gmane.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!

								Honza
-- 
Jan Kara <jack-IBi9RG/b67k@public.gmane.org>
SUSE Labs, CR