From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S943377AbcJSRvV (ORCPT ); Wed, 19 Oct 2016 13:51:21 -0400 Received: from mail-qt0-f180.google.com ([209.85.216.180]:36320 "EHLO mail-qt0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S942996AbcJSRvT (ORCPT ); Wed, 19 Oct 2016 13:51:19 -0400 MIME-Version: 1.0 In-Reply-To: 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> <94cc6deb-f93e-60ec-5834-e84a8b98e73c@arm.com> <20161018090747.GW3142@twins.programming.kicks-ass.net> <20161018103412.GT3117@twins.programming.kicks-ass.net> <20161018115651.GA20956@linaro.org> <550def7c-a0e6-b2ae-7bef-aeec6f068cfb@arm.com> From: Vincent Guittot Date: Wed, 19 Oct 2016 19:50:57 +0200 Message-ID: Subject: Re: [v4.8-rc1 Regression] sched/fair: Apply more PELT fixes To: Dietmar Eggemann Cc: Peter Zijlstra , Joseph Salisbury , Ingo Molnar , Linus Torvalds , Thomas Gleixner , LKML , Mike Galbraith , omer.akram@canonical.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id u9JHpQ7d019845 On 19 October 2016 at 17:33, Dietmar Eggemann wrote: > On 19/10/16 12:25, Vincent Guittot wrote: >> On 19 October 2016 at 11:46, Dietmar Eggemann 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 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]. This difference should be noticeable (if noticeable) only during few hundreds of ms after the creation of the task group until the load_avg has reached its real value. > > 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.