Message-ID: <CAKfTPtBarwsRLUqoMHYz82tbn4nb2QTpfa-tFzJXmu=oSdTaUg@mail.gmail.com>
Date:   Wed, 28 Sep 2016 05:00:20 -0700
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Dietmar Eggemann <dietmar.eggemann@....com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        Ingo Molnar <mingo@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Mike Galbraith <umgwanakikbuti@...il.com>,
        Yuyang Du <yuyang.du@...el.com>
Subject: Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On 28 September 2016 at 04:46, Vincent Guittot
<vincent.guittot@...aro.org> wrote:
> On 28 September 2016 at 04:31, Dietmar Eggemann
> <dietmar.eggemann@....com> wrote:
>> On 28/09/16 12:19, Peter Zijlstra wrote:
>>> On Wed, Sep 28, 2016 at 12:06:43PM +0100, Dietmar Eggemann wrote:
>>>> On 28/09/16 11:14, Peter Zijlstra wrote:
>>>>> On Fri, Sep 23, 2016 at 12:58:08PM +0100, Matt Fleming wrote:
>>
>> [...]
>>
>>>> Not sure what you mean by 'after fixing' but the se is initialized with
>>>> a possibly stale 'now' value in post_init_entity_util_avg()->
>>>> attach_entity_load_avg() before the clock is updated in
>>>> activate_task()->enqueue_task().
>>>
>>> I meant that after I fix the above issue of calling post_init with a
>>> stale clock. So the + update_rq_clock(rq) in the patch.
>>
>> OK.
>>
>> [...]
>>
>>>>> While staring at this, I don't think we can still hit
>>>>> vruntime_normalized() with a new task, so I _think_ we can remove that
>>>>> !se->sum_exec_runtime clause there (and rejoice), no?
>>>>
>>>> I'm afraid that with accurate timing we will get the same situation that
>>>> we add and subtract the same amount of load (probably 1024 now and not
>>>> 1002 (or less)) to/from cfs_rq->runnable_load_avg for the initial (fork)
>>>> hackbench run.
>>>> After all, it's 'runnable' based.
>>>
>>> The idea was that since we now update rq clock before post_init and then
>>> leave it be, both post_init and enqueue see the exact same timestamp,
>>> and the delta is 0, resulting in no aging.
>>>
>>> Or did I fail to make that happen?
>>
>> No, but IMHO what Matt wants is ageing for the hackench tasks at the end
>> of their fork phase so there is a tiny amount of
>> cfs_rq->runnable_load_avg left on cpuX after the fork related dequeue so
>> the (load-based) fork-balancer chooses cpuY for the next hackbench task.
>> That's why he wanted to avoid the __update_load_avg(se) on enqueue (thus
>> adding 1024 to cfs_rq->runnable_load_avg) and do the ageing only on
>> dequeue (removing <1024 from cfs_rq->runnable_load_avg).
>
> ok so i'm a bit confused there
> my understand of your explanation above  is that now we left a small
> amount of load in runnable_load_avg after the dequeue so another cpu
> will be chosen. But this explanation seems to be the opposite of what
> Matt said in a previous email that:
> "The performance drop comes from the fact that enqueueing/dequeueing a
> task with load 1002 during fork() results in a zero runnable_load_avg,
> which signals to the load balancer that the CPU is idle, so the next
> time we fork() we'll pick the same CPU to enqueue on -- and the cycle
> continues."

sorry forgot my question, i just misread your explanation.

Matt,

May be you can try this patch which uses utilization in
find_idlest_group. So even if runnable_load_avg is null, the
utilization should not and another cpu will be chosen
https://patchwork.kernel.org/patch/9306939/



>
>>
>>

Powered by blists - more mailing lists