[lkml]   [2016]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] sched/fair: Do not decay new task load on first enqueue
On 28 September 2016 at 04:31, Dietmar Eggemann
<> 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


 \ /
  Last update: 2016-09-28 13:47    [W:0.074 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site