From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754940AbcJLQ0p (ORCPT <rfc822;w@1wt.eu>);
        Wed, 12 Oct 2016 12:26:45 -0400
Received: from foss.arm.com ([217.140.101.70]:36930 "EHLO foss.arm.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1754884AbcJLQ0i (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 12 Oct 2016 12:26:38 -0400
Subject: Re: [PATCH 5/7 v4] sched: propagate asynchrous detach
To: Vincent Guittot <vincent.guittot@linaro.org>
References: <1474892393-5095-1-git-send-email-vincent.guittot@linaro.org>
 <1474892393-5095-6-git-send-email-vincent.guittot@linaro.org>
 <f850f7bc-b122-27c6-c8db-56c58e9627d9@arm.com>
 <CAKfTPtC0HoYfzHiokXz+o_0Fa4Z3FzSLZCQO=_RoFvEQFEfiVw@mail.gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Wanpeng Li <kernellwp@gmail.com>, Yuyang Du <yuyang.du@intel.com>,
        Morten Rasmussen <Morten.Rasmussen@arm.com>,
        Linaro Kernel Mailman List <linaro-kernel@lists.linaro.org>,
        Paul Turner <pjt@google.com>, Benjamin Segall <bsegall@google.com>
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
Message-ID: <6423eabd-cd68-e613-de3e-cd370e8a5f68@arm.com>
Date: Wed, 12 Oct 2016 17:18:29 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAKfTPtC0HoYfzHiokXz+o_0Fa4Z3FzSLZCQO=_RoFvEQFEfiVw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 12/10/16 16:45, Vincent Guittot wrote:
> On 12 October 2016 at 17:03, Dietmar Eggemann <dietmar.eggemann@arm.com> wrote:
>> On 26/09/16 13:19, Vincent Guittot wrote:

[...]

>>> @@ -6607,6 +6609,10 @@ static void update_blocked_averages(int cpu)
>>>
>>>               if (update_cfs_rq_load_avg(cfs_rq_clock_task(cfs_rq), cfs_rq, true))
>>>                       update_tg_load_avg(cfs_rq, 0);
>>> +
>>> +             /* Propagate pending load changes to the parent */
>>> +             if (cfs_rq->tg->se[cpu])
>>> +                     update_load_avg(cfs_rq->tg->se[cpu], 0);
>>
>> In my test (1 task (run/period: 8ms/16ms) in tg_root->tg_x->tg_y->*tg_z*
>> and oscillating between cpu1 and cpu2) the cfs_rq related signals are
>> nicely going down to 0 after the task has left the cpu but it doesn't
>> seem to be the case for the corresponding se (cfs_rq->tg->se[cpu])?
> 
> strange because such use case is part of the functional tests that I
> run and it was working fine according to last test that I did
> 
>>
>> It should actually work correctly because of the
>> update_tg_cfs_util/load() calls in update_load_avg(cfs_rq->tg->se[cpu],
>> 0)->propagate_entity_load_avg()
> 
> Furthermore, the update of the parent cfs_rq tg_x->cfs_rq[cpu] uses
> the delta between previous and new value for the child tg_y->se[cpu].
> So it means that if tg_x->cfs_rq[cpu]->avg.load_avg goes down to 0,
> tg_y->se[cpu]->avg.load_avg has at least changed and most probably
> goes down to 0 too

Makes sense.

> 
> Can't it be a misplaced trace point ?

Yes, you're right, it was a missing tracepoint. I only had se and cfs_rq
pelt tracepoints in __update_load_avg() and
attach/detach_entity_load_avg(). I've added them as well to
propagate_entity_load_avg() after the update_tg_cfs_load() call and now
it makes sense. Thanks!

[...]