linux-kernel - Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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: <CAKfTPtCj-Jp2RLryAGkeWv8sw55n130hX5fWO-3mopgej6+4qQ@mail.gmail.com>
Date:   Wed, 12 Oct 2016 09:41:36 +0200
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Matt Fleming <matt@...eblueprint.co.uk>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     Wanpeng Li <kernellwp@...il.com>, Ingo Molnar <mingo@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Mike Galbraith <umgwanakikbuti@...il.com>,
        Yuyang Du <yuyang.du@...el.com>,
        Dietmar Eggemann <dietmar.eggemann@....com>
Subject: Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On 11 October 2016 at 20:57, Matt Fleming <matt@...eblueprint.co.uk> wrote:
> On Tue, 11 Oct, at 03:14:47PM, Vincent Guittot wrote:
>> >
>> > I see a regression,
>> >
>> >   baseline: 2.41228
>> >   patched : 2.64528 (-9.7%)
>>
>> Just to be sure; By baseline you mean v4.8 ?
>
> Baseline is actually tip/sched/core commit 447976ef4fd0
> ("sched/irqtime: Consolidate irqtime flushing code") but I could try
> out v4.8 instead if you'd prefer that.

ok. In fact, I have noticed another regression with tip/sched/core and
hackbench while looking at yours.
I have bisect to :
10e2f1acd0 ("sched/core: Rewrite and improve select_idle_siblings")

hackbench -P -g 1

       v4.8        tip/sched/core  tip/sched/core+revert 10e2f1acd010
and 1b568f0aabf2
min 0.051       0,052               0.049
avg 0.057(0%)   0,062(-7%)   0.056(+1%)
max 0.070       0,073      0.067
stdev  +/-8%       +/-10%    +/-9%

The issue seems to be that it prevents some migration at wake up at
the end of hackbench test so we have last tasks that compete for the
same CPU whereas other CPUs are idle in the same MC domain. I haven't
to look more deeply which part of the patch do the regression yet

 >
>> >       cat /tmp/trace.$1 | grep -E "wakeup_new.*comm=hackbench" | \
>> >         sed -e 's/.*target_cpu=//' | sort | uniq -c | awk '{print $1}'
>>
>> nice command to evaluate spread
>
> Thanks!