On Fri 17-06-22 21:03:45, Damien Le Moal wrote: > On 6/17/22 20:49, Jan Kara wrote: > > On Fri 17-06-22 09:04:34, Damien Le Moal wrote: > >> 2) If IOPRIO_WHO_USER is not set, ioprio_get(IOPRIO_WHO_USER) will also > >> return the effective priority. > > > > This is the same as above. Just the calls iterate over all tasks of the > > given user... > > > >> 3) if IOPRIO_WHO_PROCESS is not set, return ? I am lost for this one. Do > >> you want to go back to IOPRIO_CLASS_NONE ? Keep default (IOPRIO_CLASS_BE) > >> ? Or switch to using the effective IO priority ? Not that the last 2 > >> choices are actually equivalent if the user did not IO nice the process > >> (the default for the effective IO prio is class BE) > > > > I want to go back to returning IOPRIO_CLASS_NONE for tasks with unset IO > > priority. > > And that would be to retain the older (broken) behavior. Because if we > consider the man page, tasks with an unset IO prio should be reported as > having the effective IO nice based priority, which is class BE if IO nice > is not set. Right ? I am OK with that, but I think we should add this > explanation as a comment somewhere in the prio code. No ? Adding a comment regarding this is certainly a good idea, I'll do that. WRT whether the old behavior is broken or not - I actually think the old behavior is more useful because it allows userspace to distinguish a situation when IO priority is set based on nice value from a situation when IO priority is set to a fixed value. Also the old behavior makes ioprio_set(pid, IOPRIO_WHO_PROCESS, ioprio_get(pid, IOPRIO_WHO_PROCESS)) a noop which is IMO a good property to have for a get/set APIs. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
