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: <CAJWu+oqojvheaT0AUS25EvvThm21DvRZP9eKq8SGQ=X4WmcJBA@mail.gmail.com>
Date:   Thu, 14 Dec 2017 09:08:27 -0800
From:   Joel Fernandes <joelaf@...gle.com>
To:     Vincent Guittot <vincent.guittot@...aro.org>
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

Hi Vincent,
Thanks for your reply.

On Thu, Dec 14, 2017 at 7:46 AM, Vincent Guittot
<vincent.guittot@...aro.org> wrote:
> Hi Joel,
>
> On 13 December 2017 at 21:00, Joel Fernandes <joelaf@...gle.com> wrote:
>> On Mon, Dec 11, 2017 at 4:43 PM, Joel Fernandes <joelaf@...gle.com> wrote:
>>> Hi Vincent,
>>>
>>>>>
>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>>> 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
>>>
>>
>> It could have been sloppy testing - I could have hit thermal
>> throttling or forgotten to stop Android runtime before running the
>> test. Looking at my old data, the case for 16 tasks has higher
>> completion times than 32 tasks which doesn't make sense. Sorry about
>> that. I was careful this time, I recreated the product tree and
>> applied patch - ran the same test as in this patch, the data prefixed
>> with "with" is with patch and "without" is without patch.
>>
>> The naming of the Test column is "<test>-<numFDs>-<numGroups>". Data
>> is completion time of hackbench in seconds.
>>
>> RUN 1:
>>
>> Test         Mean             Median            Stddev
>> with-f4-1g  0.67645 (+3.7%)  0.68000 (+3.8%)  0.025755
>> with-f4-2g  1.0685  (-0.3%)  1.0570 (+1%)       0.044122
>> with-f4-4g  1.7558  (+0.7%)  1.7685 (+0.08%)    0.096015
>>
>> without-f4-1g  0.70255  0.70750  0.025330
>> without-f4-2g  1.0653  1.0680  0.040300
>> without-f4-4g  1.7688  1.7670  0.046341
>>
>> RUN 2:
>>
>> Test         Mean          Median          Stddev
>> with-f4-1g  0.68100 (+1%)  0.67800 (+2%)   0.025543
>> with-f4-2g  1.0242 (+1.5%) 1.0260 (+1.5%)  0.042886
>> with-f4-4g  1.6100 (+3%)   1.6075 (+3.7%)  0.052677
>>
>> without-f4-1g  0.68840  0.69150  0.030988
>> without-f4-2g  1.0400  1.0420  0.034288
>> without-f4-4g  1.6636  1.6670  0.056963
>>
>>
>> Let me know what you think, thanks.
>
> The improvement has decreased compared to previous results and there

Yes but the previous result was invalid as I mentioned, I controlled
the environment better this time. Previous result showed 4g completed
quicker than 2g which wasn't very meaningful.

> is instability between your runs; As an example, run2 without patch
> does better than run1 with patchs for 2g and 4g.

That's true. The improvement percent isn't stable.

> Could you run tests on a SMP linux kernel instead of  big/LITTLE
> android in order to have a saner test environnement and remove some
> possible disturbances

Would it be Ok with you if I just dropped this synthetic test from the
patch since there are other hackbench results (case 3) from Rohit
which are on SMP?

Thanks,

- Joel