From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933965AbcJLPFN (ORCPT ); Wed, 12 Oct 2016 11:05:13 -0400 Received: from foss.arm.com ([217.140.101.70]:35354 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933243AbcJLPEC (ORCPT ); Wed, 12 Oct 2016 11:04:02 -0400 Subject: Re: [PATCH 5/7 v4] sched: propagate asynchrous detach To: Vincent Guittot , peterz@infradead.org, mingo@kernel.org, linux-kernel@vger.kernel.org, kernellwp@gmail.com References: <1474892393-5095-1-git-send-email-vincent.guittot@linaro.org> <1474892393-5095-6-git-send-email-vincent.guittot@linaro.org> Cc: yuyang.du@intel.com, Morten.Rasmussen@arm.com, linaro-kernel@lists.linaro.org, pjt@google.com, bsegall@google.com From: Dietmar Eggemann Message-ID: Date: Wed, 12 Oct 2016 16:03:20 +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: <1474892393-5095-6-git-send-email-vincent.guittot@linaro.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26/09/16 13:19, Vincent Guittot wrote: > A task can be asynchronously detached from cfs_rq when migrating > between CPUs. The load of the migrated task is then removed from > source cfs_rq during its next update. We use this event to set propagation > flag. > > During the load balance, we take advanatge of the update of blocked load > to we propagate any pending changes. IMHO, it would be a good idea to mention that '2/7 sched: fix hierarchical order in rq->leaf_cfs_rq_list' is a hard requirement for this to work. The functionality relies on the order of cfs_rq's (top to root) in the rq->leaf_cfs_rq_list list. > Signed-off-by: Vincent Guittot > --- > kernel/sched/fair.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 8ba500f..bd3b6b9 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -3221,6 +3221,7 @@ update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq, bool update_freq) > sub_positive(&sa->load_avg, r); > sub_positive(&sa->load_sum, r * LOAD_AVG_MAX); > removed_load = 1; > + set_tg_cfs_propagate(cfs_rq); > } > > if (atomic_long_read(&cfs_rq->removed_util_avg)) { > @@ -3228,6 +3229,7 @@ update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq, bool update_freq) > sub_positive(&sa->util_avg, r); > sub_positive(&sa->util_sum, r * LOAD_AVG_MAX); > removed_util = 1; > + set_tg_cfs_propagate(cfs_rq); > } > > decayed = __update_load_avg(now, cpu_of(rq_of(cfs_rq)), sa, > @@ -6607,6 +6609,10 @@ static void update_blocked_averages(int cpu) > > if (update_cfs_rq_load_avg(cfs_rq_clock_task(cfs_rq), cfs_rq, true)) > update_tg_load_avg(cfs_rq, 0); > + > + /* Propagate pending load changes to the parent */ > + if (cfs_rq->tg->se[cpu]) > + update_load_avg(cfs_rq->tg->se[cpu], 0); In my test (1 task (run/period: 8ms/16ms) in tg_root->tg_x->tg_y->*tg_z* and oscillating between cpu1 and cpu2) the cfs_rq related signals are nicely going down to 0 after the task has left the cpu but it doesn't seem to be the case for the corresponding se (cfs_rq->tg->se[cpu])? It should actually work correctly because of the update_tg_cfs_util/load() calls in update_load_avg(cfs_rq->tg->se[cpu], 0)->propagate_entity_load_avg() [...]