linux-kernel - Re: [PATCH] sched/fair: Consider RT/IRQ pressure in capacity_spare

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]

Message-ID: <CAKfTPtCpVb6ODxh9cqJRCQ1OiidLtk6RhUPa1n0Jw-Dch692GQ@mail.gmail.com>
Date:   Fri, 17 Nov 2017 09:49:56 +0100
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Joel Fernandes <joelaf@...gle.com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Morten Ramussen <morten.rasmussen@....com>,
        Brendan Jackman <brendan.jackman@....com>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        Len Brown <lenb@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...il.com>,
        Patrick Bellasi <patrick.bellasi@....com>,
        Chris Redpath <Chris.Redpath@....com>,
        Steve Muckle <smuckle@...gle.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Saravana Kannan <skannan@...cinc.com>,
        Vikram Mulukutla <vmulukut@...cinc.com>,
        Rohit Jain <rohit.k.jain@...cle.com>,
        Atish Patra <atish.patra@...cle.com>,
        EAS Dev <eas-dev@...ts.linaro.org>,
        Android Kernel <kernel-team@...roid.com>
Subject: Re: [PATCH] sched/fair: Consider RT/IRQ pressure in capacity_spare_wake

On 16 November 2017 at 22:53, Joel Fernandes <joelaf@...gle.com> wrote:
> Hi Vincent,
>
> Thanks a lot for your reply, and sorry for the late reply. Actually I
> just started paternity leave so that's why the delay. My working hours

Congratulations !

> and completely random at the moment :-)
>
> On Fri, Nov 10, 2017 at 12:29 AM, Vincent Guittot
> <vincent.guittot@...aro.org> wrote:
>> On 9 November 2017 at 19:52, Joel Fernandes <joelaf@...gle.com> wrote:
>>> capacity_spare_wake in the slow path influences choice of idlest groups,
>>> as we search for groups with maximum spare capacity. In scenarios where
>>> RT pressure is high, a sub optimal group can be chosen and hurt
>>> performance of the task being woken up.
>>>
>>> Several tests with results are included below to show improvements with
>>> this change.
>>>
>>> 1) Hackbench on Pixel 2 Android device (4x4 ARM64 Octa core)
>>
>> "4x4 ARM64 Octa core" is confusing . At least for me, 4x4 means 16 cores :-)
>
> Sure I'll fix it, I meant 4 big and 4 LITTLE CPUs :)
>
>>
>>> ------------------------------------------------------------
>>> Here we have RT activity running on big CPU cluster induced with rt-app,
>>> and running hackbench in parallel. The RT tasks are bound to 4 CPUs on
>>> the big cluster (cpu 4,5,6,7) and have 100ms periodicity with
>>> runtime=20ms sleep=80ms.
>>>
>>> Hackbench shows big benefit (30%) improvement when number of tasks is 8
>>> and 32: Note: data is completion time in seconds (lower is better).
>>> Number of loops for 8 and 16 tasks is 50000, and for 32 tasks its 20000.
>>> +--------+-----+-------+-------------------+---------------------------+
>>> | groups | fds | tasks | Without Patch     | With Patch                |
>>> +--------+-----+-------+---------+---------+-----------------+---------+
>>> |        |     |       | Mean    | Stdev   | Mean            | Stdev   |
>>> |        |     |       +-------------------+-----------------+---------+
>>> |      1 |   8 |     8 | 1.0534  | 0.13722 | 0.7293 (+30.7%) | 0.02653 |
>>> |      2 |   8 |    16 | 1.6219  | 0.16631 | 1.6391 (-1%)    | 0.24001 |
>>> |      4 |   8 |    32 | 1.2538  | 0.13086 | 1.1080 (+11.6%) | 0.16201 |
>>> +--------+-----+-------+---------+---------+-----------------+---------+
>>
>>  Out of curiosity, do you know why you don't see any improvement for
>> 16 tasks but only for 8 and 32 tasks ?
>
> Yes I'm not fully sure why 16 tasks didn't show that much improvement.

Yes. This is just to make sure that there no unexpected side effect

> I can try to trace it when I can get a chance. Generally for this
> test, with more number of tasks, the improvement is lesser. However
> you're right to point out that the improvement with 32 is > with 16
> for this test.
>
> [..]
>>>  kernel/sched/fair.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>> index 56f343b8e749..ba9609407cb9 100644
>>> --- a/kernel/sched/fair.c
>>> +++ b/kernel/sched/fair.c
>>> @@ -5724,7 +5724,7 @@ static int cpu_util_wake(int cpu, struct task_struct *p);
>>>
>>>  static unsigned long capacity_spare_wake(int cpu, struct task_struct *p)
>>>  {
>>> -       return capacity_orig_of(cpu) - cpu_util_wake(cpu, p);
>>> +       return max_t(long, capacity_of(cpu) - cpu_util_wake(cpu, p), 0);
>>
>> Make sense
>>
>> Reviewed-by: Vincent Guittot <vincent.guittot@...aro.org>
>
> Thanks!
>
> - Joel