From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753728AbbDJBhJ (ORCPT ); Thu, 9 Apr 2015 21:37:09 -0400 Received: from mail-wg0-f42.google.com ([74.125.82.42]:36666 "EHLO mail-wg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751310AbbDJBhG (ORCPT ); Thu, 9 Apr 2015 21:37:06 -0400 Date: Fri, 10 Apr 2015 03:37:03 +0200 From: Frederic Weisbecker To: Chris Metcalf Cc: "Peter Zijlstra (Intel)" , "Paul E. McKenney" , "Rafael J. Wysocki" , Martin Schwidefsky , Ingo Molnar , linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 2/2] nohz: set isolcpus when nohz_full is set Message-ID: <20150410013702.GF18314@lerouge> References: <20150409174218.GT21418@twins.programming.kicks-ass.net> <1428602506-16753-1-git-send-email-cmetcalf@ezchip.com> <1428602506-16753-2-git-send-email-cmetcalf@ezchip.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1428602506-16753-2-git-send-email-cmetcalf@ezchip.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 09, 2015 at 02:01:46PM -0400, Chris Metcalf wrote: > nohz_full is only useful with isolcpus also set, since otherwise the > scheduler has to run periodically to try to determine whether to steal > work from other cores. > > Accordingly, when booting with nohz_full=xxx on the command line, we > should act as if isolcpus=xxx was also set, and set (or extend) the > isolcpus set to include the nohz_full cpus. > > Signed-off-by: Chris Metcalf > --- > I've come full circle on this issue. For v5 I liked Frederic's > idea of adding an API, but the more I thought about it seemed > like an overly-generic mechanism for what is really a very specific > issue, namely the interaction between the scheduler and nohz_full. > We already have plenty of nohz_full-specific code in sched/core.c, > and I think we now have a cpumask function name that is OK, so > now I'm proposing we just stick with directly modifying the > cpu_isolated_map using the new name. However, I've moved the > update to the map right to the top of sched_init_smp(), which seems > like a cleaner place to make this kind of a change. > > v6: back to just using a direct update, with the new names > > v5: test run of Frederic's proposal to use sched_isolated_map_add() > > v4: update accessor names to make them clearer [PeterZ] > > v3: update changelog language to avoid using unclear "implies" [PeterZ] > > kernel/sched/core.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index f0f831e8a345..041845c568d2 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -7031,6 +7031,9 @@ void __init sched_init_smp(void) > alloc_cpumask_var(&non_isolated_cpus, GFP_KERNEL); > alloc_cpumask_var(&fallback_doms, GFP_KERNEL); > > + /* nohz_full won't take effect without isolating the cpus. */ > + tick_nohz_full_remove_cpus_from(cpu_isolated_map); This should be the other one I guess. > + > sched_init_numa(); > > /* > -- > 2.1.2 >