From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S943435AbcJSOx0 (ORCPT ); Wed, 19 Oct 2016 10:53:26 -0400 Received: from mail-qt0-f172.google.com ([209.85.216.172]:35387 "EHLO mail-qt0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S942157AbcJSOxX (ORCPT ); Wed, 19 Oct 2016 10:53:23 -0400 MIME-Version: 1.0 In-Reply-To: <8b29f878-29bc-8efa-6d34-d5df3b68e020@canonical.com> 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> <8b29f878-29bc-8efa-6d34-d5df3b68e020@canonical.com> From: Vincent Guittot Date: Wed, 19 Oct 2016 16:53:01 +0200 Message-ID: Subject: Re: [v4.8-rc1 Regression] sched/fair: Apply more PELT fixes To: Joseph Salisbury Cc: Peter Zijlstra , Dietmar Eggemann , 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 u9JErfUJ017366 On 19 October 2016 at 16:49, Joseph Salisbury wrote: > On 10/18/2016 07:56 AM, 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: >>>>> So aside from funny BIOSes, this should also show up when creating >>>>> cgroups when you have offlined a few CPUs, which is far more common I'd >>>>> think. >>>> The problem is also that the load of the tg->se[cpu] that represents >>>> the tg->cfs_rq[cpu] is initialized to 1024 in: >>>> alloc_fair_sched_group >>>> for_each_possible_cpu(i) { >>>> init_entity_runnable_average(se); >>>> sa->load_avg = scale_load_down(se->load.weight); >>>> >>>> Initializing sa->load_avg to 1024 for a newly created task makes >>>> sense as we don't know yet what will be its real load but i'm not sure >>>> that we have to do the same for se that represents a task group. This >>>> load should be initialized to 0 and it will increase when task will be >>>> moved/attached into task group >>> Yes, I think that makes sense, not sure how horrible that is with the >> That should not be that bad because this initial value is only useful for >> the few dozens of ms that follow the creation of the task group >> >>> current state of things, but after your propagate patch, that >>> reinstates the interactivity hack that should work for sure. >> The patch below fixes the issue on my platform: >> >> Dietmar, Omer can you confirm that this fix the problem of your platform too ? >> >> --- >> kernel/sched/fair.c | 9 ++++++++- >> 1 file changed, 8 insertions(+), 1 deletion(-)Vinc >> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index 8b03fb5..89776ac 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@ -690,7 +690,14 @@ void init_entity_runnable_average(struct sched_entity *se) >> * will definitely be update (after enqueue). >> */ >> sa->period_contrib = 1023; >> - sa->load_avg = scale_load_down(se->load.weight); >> + /* >> + * Tasks are intialized with full load to be seen as heavy task until >> + * they get a chance to stabilize to their real load level. >> + * group entity are intialized with null load to reflect the fact that >> + * nothing has been attached yet to the task group. >> + */ >> + if (entity_is_task(se)) >> + sa->load_avg = scale_load_down(se->load.weight); >> sa->load_sum = sa->load_avg * LOAD_AVG_MAX; >> /* >> * At this point, util_avg won't be used in select_task_rq_fair anyway >> >> >> >> > Omer also reports that this patch fixes the bug for him as well. Thanks > for the great work, Vincent! Thanks >