Re: [PATCH 8/8] block: Always initialize bio IO priority on submit

[Jan Kara <jack@suse.cz>]

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@suse.com>
SUSE Labs, CR