From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S945679AbcJSPpr (ORCPT ); Wed, 19 Oct 2016 11:45:47 -0400 Received: from foss.arm.com ([217.140.101.70]:53736 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S942001AbcJSOfD (ORCPT ); Wed, 19 Oct 2016 10:35:03 -0400 Subject: Re: [v4.8-rc1 Regression] sched/fair: Apply more PELT fixes To: Vincent Guittot , Peter Zijlstra 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> Cc: Joseph Salisbury , Ingo Molnar , Linus Torvalds , Thomas Gleixner , LKML , Mike Galbraith , omer.akram@canonical.com From: Dietmar Eggemann Message-ID: <550def7c-a0e6-b2ae-7bef-aeec6f068cfb@arm.com> Date: Wed, 19 Oct 2016 10:46:14 +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: <20161018115651.GA20956@linaro.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: [...] > > The patch below fixes the issue on my platform: > > Dietmar, Omer can you confirm that this fix the problem of your platform too ? It fixes this broken BIOS issue on my T430 ( cpu_possible_mask > cpu_online_mask). I ran the original test with the cpu hogs (stress -c 4). Launch time of applications becomes normal again. Tested-by: Dietmar Eggemann 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'. > --- > kernel/sched/fair.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > 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