Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp3098891ybz; Sun, 3 May 2020 17:15:54 -0700 (PDT) X-Google-Smtp-Source: APiQypJBH3UqMJdpYGBGlA2gym8NQTfqvqt7UZP9iz5/rmuYRJh9WN0+daEHlUlyKdZ28+XsKlWP X-Received: by 2002:aa7:d3d3:: with SMTP id o19mr12541170edr.76.1588551354086; Sun, 03 May 2020 17:15:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588551354; cv=none; d=google.com; s=arc-20160816; b=UpU3JHPe5iiPDUj19Wqma8RIwNLS7H/OPR2LAfPuVbOE5nTmCYBzt9p4cqmli+RjpF 14mV5MmF3wALPbLcjbscYDXvJKuy6wVMTs6USAbbn3i1jJw1Rzqbwd/qS+NqHTGuLahD 0v93wpyoM1AtlKfCBoRD8hsg5hY3wQqA8Z4Ww95EwHoOlWdVsJ+os5Pp8HlYEYfAs7EK lrMcDkJCwOxhQDY3H8X5YN8ia55tLh4ffAxHddlG4y0DQXDATYHbf37YjH6NrdQSwugT nF96SrRRnzDPLvADb0YrdebG9B5BwOGcJMLYqemTemP+wAP3QQ7aXLmnmUrKQL81AVwO s3xw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:in-reply-to :subject:cc:to:from:user-agent:references; bh=ue05Dw7WMyCiJnnQ1FtEYn3I0j6oKXFL/GNx+SiNNSs=; b=0kkeezkyNMwvzIleVbb4Y6FG1TeuDla6HMlOPruu+7C9O2us0N2nGclkM7y8eFogAQ 7f6tjGn8S3+rXTSIMU2rNBztNX2QUEk6ME6RaqYIGDttJYRUx5NyGct4vYMVTfSCzu/h jMY+jV/G7s57KzHMEL1ZqhCjiIhZ53bN1LXCTerAM40bDRqTzu97Om2X/yxPO2sc4FQ3 kbvx8tz/6i9ozotD5Hyx+QlaRW8U6PNZ+pmiEagOggkTfxXf+YiuwfSlotax5UonsD/S 7q1EIeRnDAbJlMGCMFmuQrEAY6n6R15p6Jb5zM1tHDTimDPJd+XyVuYnBd6oaKnaTzSw 5A1Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p22si5836661edx.177.2020.05.03.17.15.31; Sun, 03 May 2020 17:15:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726761AbgEDAKu (ORCPT + 99 others); Sun, 3 May 2020 20:10:50 -0400 Received: from foss.arm.com ([217.140.110.172]:34614 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726421AbgEDAKu (ORCPT ); Sun, 3 May 2020 20:10:50 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BA297101E; Sun, 3 May 2020 17:10:49 -0700 (PDT) Received: from e113632-lin (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 64D273F305; Sun, 3 May 2020 17:10:48 -0700 (PDT) References: <20200503083407.GA27766@iZj6chx1xj0e0buvshuecpZ> User-agent: mu4e 0.9.17; emacs 26.3 From: Valentin Schneider To: Peng Liu Cc: linux-kernel@vger.kernel.org, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de Subject: Re: [PATCH] sched/fair: Fix nohz.next_balance update In-reply-to: <20200503083407.GA27766@iZj6chx1xj0e0buvshuecpZ> Date: Mon, 04 May 2020 01:10:46 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 03/05/20 09:34, Peng Liu wrote: > commit c5afb6a87f23 ("sched/fair: Fix nohz.next_balance update") I got confused because this has the same topic as your patch, but that's a genuine commit from 2015. Is this meant to be a "Fixes:" reference? > During idle load balance, this_cpu(ilb) do load balance for the other > idle CPUs, also gather the earliest (nohz.)next_balance. > > Since commit: > 'b7031a02ec75 ("sched/fair: Add NOHZ_STATS_KICK")' > > We update nohz.next_balance like this: > > _nohz_idle_balance() { > for_each_cpu(nohz.idle_cpus_mask) { > rebalance_domains() { > update nohz.next_balance <-- compare and update > } > } > rebalance_domains(this_cpu) { > update nohz.next_balance <-- compare and update > } > update nohz.next_balance <-- unconditionally update > } > > For instance, nohz.idle_cpus_mask spans {cpu2,3,5,8}, and this_cpu is > cpu5. After the above loop we could gather the earliest *next_balance* > among {cpu2,3,8}, then rebalance_domains(this_cpu) update > nohz.next_balance with this_rq->next_balance, but finally overwrite > nohz.next_balance with the earliest *next_balance* among {cpu2,3,8}, > we may end up with not getting the earliest next_balance. > That does look like it, nice catch! > Since we can gather all the updated rq->next_balance, including this_cpu, > in _nohz_idle_balance(), it's safe to remove the extra lines in > rebalance_domains() which are originally intended for this_cpu. And > finally the updating only happen in _nohz_idle_balance(). > One added benefit of this is that we get rid of extra writes to nohz.next_balance, since that special case in rebalance_domains() could be hit by all NOHZ CPUs, not just the ILB. With the below comment taken into account: Reviewed-by: Valentin Schneider > Signed-off-by: Peng Liu > Cc: Ingo Molnar > Cc: Peter Zijlstra > Cc: Juri Lelli > Cc: Vincent Guittot > Cc: Dietmar Eggemann > Cc: Steven Rostedt > Cc: Ben Segall > Cc: Mel Gorman > Cc: Valentin Schneider > --- > kernel/sched/fair.c | 24 ++++++++---------------- > 1 file changed, 8 insertions(+), 16 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 02f323b85b6d..1d0cf33fefad 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -9943,22 +9943,8 @@ static void rebalance_domains(struct rq *rq, enum cpu_idle_type idle) > * When the cpu is attached to null domain for ex, it will not be > * updated. > */ > - if (likely(update_next_balance)) { > + if (likely(update_next_balance)) > rq->next_balance = next_balance; > - > -#ifdef CONFIG_NO_HZ_COMMON > - /* > - * If this CPU has been elected to perform the nohz idle > - * balance. Other idle CPUs have already rebalanced with > - * nohz_idle_balance() and nohz.next_balance has been > - * updated accordingly. This CPU is now running the idle load > - * balance for itself and we need to update the > - * nohz.next_balance accordingly. > - */ > - if ((idle == CPU_IDLE) && time_after(nohz.next_balance, rq->next_balance)) > - nohz.next_balance = rq->next_balance; > -#endif > - } > } > > static inline int on_null_domain(struct rq *rq) > @@ -10321,9 +10307,15 @@ static bool _nohz_idle_balance(struct rq *this_rq, unsigned int flags, > has_blocked_load |= this_rq->has_blocked_load; > } > > - if (flags & NOHZ_BALANCE_KICK) > + if (flags & NOHZ_BALANCE_KICK) { > rebalance_domains(this_rq, CPU_IDLE); > > + if (time_after(next_balance, this_rq->next_balance)) { > + next_balance = this_rq->next_balance; > + update_next_balance = 1; > + } > + } To align with what we do for the other NOHZ CPUs, shouldn't this update be outside of the NOHZ_BALANCE_KICK condition? That way we can update nohz.next_balance with just NOHZ_STATS_KICK, which IMO is the expected course of action. > + > WRITE_ONCE(nohz.next_blocked, > now + msecs_to_jiffies(LOAD_AVG_PERIOD));