[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170315120428.GC18557@e110439-lin>
Date: Wed, 15 Mar 2017 12:04:28 +0000
From: Patrick Bellasi <patrick.bellasi@....com>
To: Joel Fernandes <joelaf@...gle.com>
Cc: linux-kernel@...r.kernel.org, Juri Lelli <Juri.Lelli@....com>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH] sched: write better comments for weight calculations
Few comments inline, otherwise LGTM.
Cheers Patrick
On 10-Mar 12:47, Joel Fernandes wrote:
> This patch rewrites comments related task priorities and CPU usage
> along with an example to show how it works.
>
> Cc: Juri Lelli <Juri.Lelli@....com>
> Cc: Patrick Bellasi <patrick.bellasi@....com>
> Cc: Dietmar Eggemann <dietmar.eggemann@....com>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Ingo Molnar <mingo@...hat.com>
> Signed-off-by: Joel Fernandes <joelaf@...gle.com>
> ---
> kernel/sched/core.c | 27 +++++++++++++++++++--------
> 1 file changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index c56fb57f2991..2175bf663f3d 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -8823,16 +8823,27 @@ void dump_cpu_task(int cpu)
> }
>
> /*
> - * Nice levels are multiplicative, with a gentle 10% change for every
> - * nice level changed. I.e. when a CPU-bound task goes from nice 0 to
> - * nice 1, it will get ~10% less CPU time than another CPU-bound task
> - * that remained on nice 0.
> + * Nice levels are multiplicative, with a gentle 10% relative change
> + * for every nice level changed. I.e. if there were 2 CPU-bound tasks
> + * of equal nice value and one of them goes from a nice level of 0 to 1
> + * then the task at nice level 1 will get ~5% less CPU time than before
> + * the change and the task that remained at nice level 0 will get ~5%
> + * more CPU time.
> *
> * The "10% effect" is relative and cumulative: from _any_ nice level,
> - * if you go up 1 level, it's -10% CPU usage, if you go down 1 level
> - * it's +10% CPU usage. (to achieve that we use a multiplier of 1.25.
> - * If a task goes up by ~10% and another task goes down by ~10% then
> - * the relative distance between them is ~25%.)
> + * if you go up 1 level, it's -10% relative CPU usage, if you go down
> + * by 1 level it's +10% CPU usage.
^
relative
> + * To achieve that, we use a multiplier of 1.25.
The following sentence:
> + * If a task goes up by ~5% and another task goes down by ~5%
> + * then the relative distance between their weights is ~25% as shown
> + * in the following example:
is still confusing to me, mainly because we are mixing the "shares
percentage" with the CPU usage percentage.
What about this:
If two tasks have a 25% relative distance between their weights
then they will get a 10% difference in CPU usage as shown in the
following example.
> + *
> + * Consider 2 tasks T1 and T2 which are scheduled within a sched_period
> + * of 10ms. Say T1 has a nice value 0 and T2 has a nice value 1,
> + * then their corresponding weights are 1024 for T1 and 820 for T2.
> + *
> + * The relative delta between their weights is ~25% (1.25 * 820 ~= 1024)
> + * T1's CPU slice = (1024 / (820 + 1024)) * 10 ~= 5.5ms (55% usage)
^
ms
> + * T2's CPU slice = (820 / (820 + 1024)) * 10 ~= 4.5ms (45% usage)
^
ms
> */
> const int sched_prio_to_weight[40] = {
> /* -20 */ 88761, 71755, 56483, 46273, 36291,
> --
> 2.12.0.246.ga2ecc84866-goog
>
--
#include <best/regards.h>
Patrick Bellasi
Powered by blists - more mailing lists