Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S946179AbcJSRdX (ORCPT ); Wed, 19 Oct 2016 13:33:23 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:60736 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S945567AbcJSRdU (ORCPT ); Wed, 19 Oct 2016 13:33:20 -0400 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org A602761886 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=pass smtp.mailfrom=joonwoop@codeaurora.org Date: Wed, 19 Oct 2016 10:33:16 -0700 From: Joonwoo Park To: Dietmar Eggemann Cc: Vincent Guittot , Peter Zijlstra , Joseph Salisbury , Ingo Molnar , Linus Torvalds , Thomas Gleixner , LKML , Mike Galbraith , omer.akram@canonical.com Subject: Re: [v4.8-rc1 Regression] sched/fair: Apply more PELT fixes Message-ID: <20161019173316.jambi4dnt44bn55u@codeaurora.org> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.1-neo (2016-06-11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2733 Lines: 67 On Wed, Oct 19, 2016 at 04:33:03PM +0100, 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 is the exact thing I was also worried about and that's the reason I tried to fix this in a different way. However I didn't find any behaviour difference once any task attached to child cfs_rq which is the point we really care about. I found this bug while making patch at https://lkml.org/lkml/2016/10/18/841 which will fail with wrong task_group load_avg. I tested Vincent's patch and above together, confirmed it's still good. Though I know Ingo already sent out pull request. Anyway. Tested-by: Joonwoo Park Thanks, Joonwoo > > 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.