MIME-Version: 1.0
In-Reply-To: <20161011185759.GD16071@codeblueprint.co.uk>
References: <20160923115808.2330-1-matt@codeblueprint.co.uk>
 <20160928101422.GR5016@twins.programming.kicks-ass.net> <20160928193731.GD16071@codeblueprint.co.uk>
 <CANRm+CyVFuT3XJt7DZEBZgHb_hQPzDUfOGnkAqNexH4q2ex74Q@mail.gmail.com>
 <20161010100107.GZ16071@codeblueprint.co.uk> <CAKfTPtBFrahA2fBoG5S5CBiJHb8EZkUbPaOZ4jZFc1mVYH5zJQ@mail.gmail.com>
 <20161010173440.GA28945@linaro.org> <20161011102453.GA16071@codeblueprint.co.uk>
 <CAKfTPtCKxu=39wbcDW5hioGnWxmGnSoYiu_oMfQEWObwBKzG5w@mail.gmail.com> <20161011185759.GD16071@codeblueprint.co.uk>
From: Vincent Guittot <vincent.guittot@linaro.org>
Date: Wed, 12 Oct 2016 09:41:36 +0200
Message-ID: <CAKfTPtCj-Jp2RLryAGkeWv8sw55n130hX5fWO-3mopgej6+4qQ@mail.gmail.com>
Subject: Re: [PATCH] sched/fair: Do not decay new task load on first enqueue
To: Matt Fleming <matt@codeblueprint.co.uk>,
        Peter Zijlstra <peterz@infradead.org>
Cc: Wanpeng Li <kernellwp@gmail.com>, Ingo Molnar <mingo@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Mike Galbraith <umgwanakikbuti@gmail.com>,
        Yuyang Du <yuyang.du@intel.com>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1374
Lines: 40

On 11 October 2016 at 20:57, Matt Fleming <matt@codeblueprint.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!