Messages in this thread | | | Date | Wed, 1 Feb 2023 10:56:03 -0500 | From | Steven Rostedt <> | Subject | Re: [PATCH] kernel/sched/core: adjust rt_priority accordingly when prio is changed |
| |
On Wed, 1 Feb 2023 18:01:20 +0800 Song Chen <chensong_2000@189.cn> wrote:
> When a high priority process is acquiring a rtmutex which is held by a > low priority process, the latter's priority will be boosted up by calling > rt_mutex_setprio->__setscheduler_prio. > > However, p->prio is changed but p->rt_priority is not, as a result, the > equation between prio and rt_priority is broken, which is: > > prio = MAX_RT_PRIO - 1 - rt_priority > > It's confusing to the user when it calls sched_getparam, which only > returns rt_priority.
If it is boosted, then that's an internal implementation and not the real priority of the task. It should not be exposed to a user interface. In fact, there's discussion of implementing a "proxy" algorithm which will make what the "priority" of a task is even more complicated when acquiring mutexes.
> > This patch addresses this issue by adjusting rt_priority according to > the new value of prio, what's more, it also returns normal_prio for > CFS processes instead of just a zero.
The comment above sched_getparam() is:
/** * sys_sched_getparam - get the RT priority of a thread * @pid: the pid in question. * @param: structure containing the RT priority. * * Return: On success, 0 and the RT priority is in @param. Otherwise, an error * code. */
So returning the nice value is incorrect. If anything, perhaps it should return -EINVAL if the task is not an RT task?
-- Steve
> > Signed-off-by: Song Chen <chensong_2000@189.cn> > ---
| |