From: Peter Zijlstra <peterz@infradead.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
tglx@linutronix.de, John Ogness <john.ogness@linutronix.de>,
richard@nod.at
Subject: Re: [PATCH] sched: Document that RT task priorities are 1…99
Date: Mon, 17 Jun 2019 14:24:48 +0200 [thread overview]
Message-ID: <20190617122448.GA3436@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20190403210821.10916-1-bigeasy@linutronix.de>
On Wed, Apr 03, 2019 at 11:08:21PM +0200, Sebastian Andrzej Siewior wrote:
> John identified three files which claim that RT task priorities start at
> zero. As far as I understand, 0 is used for DL and has nothing to do
> wihich RT priorities as identified by the RT policy.
>
> Correct the comment, valid RT priorities are in the range from 1 to 99.
It all depends on what view I'm afraid. User priorities go from 1-99, as
per sched_get_priority_{min,max}(), but Kernel priority is:
kernel_prio := MAX_RT_PRIO-1 - user_prio
and that then gives [0-98], where 0 is max and 98 is min (see
__sched_setscheduler() and normal_prio()).
And DL uses kernel prio -1 (there is no user prio equivalent).
Nice maps to:
kernel_prio := MAX_RT_PRIO + (MAX_NICE - MIN_NICE + 1) / 2 + user_nice
which is: [100-139].
Which then, as derRichard says, leaves (kernel) 99 unaccounted for.
> Reported-by: John Ogness <john.ogness@linutronix.de>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> Documentation/scheduler/sched-rt-group.txt | 2 +-
> include/linux/sched/prio.h | 2 +-
> kernel/sched/cpupri.h | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/scheduler/sched-rt-group.txt b/Documentation/scheduler/sched-rt-group.txt
> index d8fce3e784574..23f8f8465a775 100644
> --- a/Documentation/scheduler/sched-rt-group.txt
> +++ b/Documentation/scheduler/sched-rt-group.txt
> @@ -175,7 +175,7 @@ get their allocated time.
>
> Implementing SCHED_EDF might take a while to complete. Priority Inheritance is
> the biggest challenge as the current linux PI infrastructure is geared towards
> -the limited static priority levels 0-99. With deadline scheduling you need to
> +the limited static priority levels 1-99. With deadline scheduling you need to
> do deadline inheritance (since priority is inversely proportional to the
> deadline delta (deadline - now)).
>
This might be correct,.. but I feel we should strive to delete
everything rt groups.
> diff --git a/include/linux/sched/prio.h b/include/linux/sched/prio.h
> index 7d64feafc408e..6986c32356842 100644
> --- a/include/linux/sched/prio.h
> +++ b/include/linux/sched/prio.h
> @@ -8,7 +8,7 @@
>
> /*
> * Priority of a process goes from 0..MAX_PRIO-1, valid RT
> - * priority is 0..MAX_RT_PRIO-1, and SCHED_NORMAL/SCHED_BATCH
> + * priority is 1..MAX_RT_PRIO-1, and SCHED_NORMAL/SCHED_BATCH
> * tasks are in the range MAX_RT_PRIO..MAX_PRIO-1. Priority
> * values are inverted: lower p->prio value means higher priority.
> *
So that comment talks about kernel prio, and there, as we've shown, 0 is
an actual valid RR/FIFO priority (in fact, the highest).
> diff --git a/kernel/sched/cpupri.h b/kernel/sched/cpupri.h
> index 7dc20a3232e72..40257a97fb8f2 100644
> --- a/kernel/sched/cpupri.h
> +++ b/kernel/sched/cpupri.h
> @@ -5,7 +5,7 @@
> #define CPUPRI_INVALID -1
> #define CPUPRI_IDLE 0
> #define CPUPRI_NORMAL 1
> -/* values 2-101 are RT priorities 0-99 */
> +/* values 2-101 are RT priorities 1-99 */
Again, this is kernel prios, not user prios.
> struct cpupri_vec {
> atomic_t count;
> --
> 2.20.1
>
prev parent reply other threads:[~2019-06-17 12:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-03 21:08 [PATCH] sched: Document that RT task priorities are 1…99 Sebastian Andrzej Siewior
2019-04-03 21:17 ` John Ogness
2019-04-04 7:45 ` John Ogness
2019-04-16 8:13 ` [tip:sched/core] sched/core: Document that RT task priorities are 1...99 tip-bot for Sebastian Andrzej Siewior
2019-04-16 9:36 ` Peter Zijlstra
2019-04-16 9:47 ` Sebastian Andrzej Siewior
2019-04-16 11:22 ` Peter Zijlstra
2019-04-16 12:08 ` Sebastian Andrzej Siewior
2019-04-16 12:43 ` John Ogness
2019-06-17 12:24 ` Peter Zijlstra [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190617122448.GA3436@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bigeasy@linutronix.de \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=richard@nod.at \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.