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@xxxxxxx/). >>>> 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
