linux-kernel - Re: [PATCH] sched: write better comments for weight calculations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 15 Mar 2017 05:35:28 -0700
From:   Joel Fernandes <joelaf@...gle.com>
To:     Patrick Bellasi <patrick.bellasi@....com>
Cc:     LKML <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

On Wed, Mar 15, 2017 at 5:04 AM, Patrick Bellasi
<patrick.bellasi@....com> wrote:
> Few comments inline, otherwise LGTM.

Ok, I'll take that as an Acked-by with the following comment addressed
if that's Ok with you.

>
> 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.

I agree your statement is clearer and I will use it in the repost.

J.