Subject: Re: [v4.8-rc1 Regression] sched/fair: Apply more PELT fixes
To: Vincent Guittot <vincent.guittot@linaro.org>
References: <20161014151827.GA10379@linaro.org>
 <2bb765e7-8a5f-c525-a6ae-fbec6fae6354@canonical.com>
 <20161017090903.GA11962@linaro.org>
 <4e15ad55-beeb-e860-0420-8f439d076758@arm.com>
 <20161017131952.GR3117@twins.programming.kicks-ass.net>
 <CAKfTPtAxw1b-vy285HKtPUBFYuJdv2CFZH_gP3CMtZHs1wLPXg@mail.gmail.com>
 <94cc6deb-f93e-60ec-5834-e84a8b98e73c@arm.com>
 <20161018090747.GW3142@twins.programming.kicks-ass.net>
 <CAKfTPtCH4wbzHaDzgAtLLSLUegQfztgE5bO4JV-SYxEGd78KGA@mail.gmail.com>
 <20161018103412.GT3117@twins.programming.kicks-ass.net>
 <20161018115651.GA20956@linaro.org>
 <550def7c-a0e6-b2ae-7bef-aeec6f068cfb@arm.com>
 <CAKfTPtBUfBz7q+w0JfT_3_18NteDF0BQfhRWsraJGY06U74hdw@mail.gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
        Joseph Salisbury <joseph.salisbury@canonical.com>,
        Ingo Molnar <mingo@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>, Mike Galbraith <efault@gmx.de>,
        omer.akram@canonical.com
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
Message-ID: <ee53f6b5-0fc9-537a-14ee-bfff87338369@arm.com>
Date: Wed, 19 Oct 2016 16:33:03 +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: <CAKfTPtBUfBz7q+w0JfT_3_18NteDF0BQfhRWsraJGY06U74hdw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2006
Lines: 49

On 19/10/16 12:25, Vincent Guittot wrote:
> On 19 October 2016 at 11:46, Dietmar Eggemann <dietmar.eggemann@arm.com> wrote:
>> On 18/10/16 12:56, Vincent Guittot wrote:
>>> Le Tuesday 18 Oct 2016 à 12:34:12 (+0200), Peter Zijlstra a écrit :
>>>> On Tue, Oct 18, 2016 at 11:45:48AM +0200, Vincent Guittot wrote:
>>>>> On 18 October 2016 at 11:07, Peter Zijlstra <peterz@infradead.org> wrote:

[...]

>> But this test only makes sure that we don't see any ghost contribution
>> (from non-existing cpus) any more.
>>
>> We should study the tg->se[i]->avg.load_avg for the hierarchy of tg's
>> (with the highest tg having a task enqueued) a little bit more, with and
>> without your v5 'sched: reflect sched_entity move into task_group's load'.
> 
> Can you elaborate ?

I try :-)

I thought I will see some different behaviour because of the fact that
the tg se's are initialized differently [1024 versus 0].

But I can't spot any difference. The test case is running a sysbench
thread affine to cpu1 in tg_root/tg_1/tg_11/tg_111 on tip/sched/core on
an ARM64 Juno (6 logical cpus).
The moment the sysbench task is put into tg_111
tg_111->se[1]->avg.load_avg gets updated to 0 any way because of the
huge time difference between creating this tg and attaching a task to
it. So the tg->se[2]->avg.load_avg signals for tg_111, tg_11 and tg_1
look exactly the same w/o and w/ your patch.

But your patch helps in this (very synthetic) test case as well. W/o
your patch I see remaining tg->load_avg for tg_1 and tg_11 after the
test case has finished because the tg's were exclusively used on cpu1.

# cat /proc/sched_debug

 cfs_rq[1]:/tg_1
   .tg_load_avg_contrib           : 0
   .tg_load_avg                   : 5120 (5 (unused cpus) * 1024 * 1)
 cfs_rq[1]:/tg_1/tg_11/tg_111
   .tg_load_avg_contrib           : 0
   .tg_load_avg                   : 0
 cfs_rq[1]:/tg_1/tg_11
   .tg_load_avg_contrib           : 0
   .tg_load_avg                   : 5120

With your patch applied all the .tg_load_avg are 0.