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

From: Vincent Guittot
Date: Wed Oct 12 2016 - 03:44:52 EST


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