From patchwork Mon Aug 5 04:25:13 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolas Pitre X-Patchwork-Id: 2838523 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 26D119F3B9 for ; Mon, 5 Aug 2013 04:33:12 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 13C3220179 for ; Mon, 5 Aug 2013 04:33:11 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E37822017A for ; Mon, 5 Aug 2013 04:33:09 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1V6CTj-0008UW-N3; Mon, 05 Aug 2013 04:33:07 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1V6CTh-000112-GF; Mon, 05 Aug 2013 04:33:05 +0000 Received: from mail-qa0-f47.google.com ([209.85.216.47]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1V6CTe-00010U-OT for linux-arm-kernel@lists.infradead.org; Mon, 05 Aug 2013 04:33:03 +0000 Received: by mail-qa0-f47.google.com with SMTP id o19so744455qap.13 for ; Sun, 04 Aug 2013 21:32:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type:x-gm-message-state; bh=hcZPWxcg0/OY9/43SsRIqecGjCL9buNSUHISk0hpbzQ=; b=j9T3Yq0GIzzZ8gdVQMpdiGLhAVNZwN4xihP7KPsuiVUT9wAzi7xIreBB4QR266Sit6 6m+HFN4OhdhxQVyB52joLMCTSR1bgz2eZOlJzAqrP1hQYKErYg7qZrkDXiRml2aGd4GJ 22egl5mdHx6VZqGXZ1oWZF2DraE6gpmF5xlJfhuJDMMD0f0IP0JymtIeBNaqzUGBYlFY +OVVHKWKbKEAXFza+c25NehYKGxKY/QjpyIsZ6QYSqzeTka9C5js3w3A6KTxL95a1GUv G4fFgPuzQEGiS9PyJ10gtKA9f97w78KzT/R/rgd+Fdm2brusm6KSbwJ+QGJvBG6J+thr SDhg== X-Received: by 10.229.118.133 with SMTP id v5mr1682234qcq.93.1375676715319; Sun, 04 Aug 2013 21:25:15 -0700 (PDT) Received: from xanadu.home (modemcable044.209-83-70.mc.videotron.ca. [70.83.209.44]) by mx.google.com with ESMTPSA id i1sm989406qas.10.2013.08.04.21.25.14 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 04 Aug 2013 21:25:14 -0700 (PDT) Date: Mon, 5 Aug 2013 00:25:13 -0400 (EDT) From: Nicolas Pitre To: Lorenzo Pieralisi Subject: Re: [PATCH 11/13] ARM: bL_switcher: veto CPU hotplug requests when the switcher is active In-Reply-To: <20130731103025.GC6583@e102568-lin.cambridge.arm.com> Message-ID: References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org> <1374550289-25305-12-git-send-email-nicolas.pitre@linaro.org> <20130731103025.GC6583@e102568-lin.cambridge.arm.com> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 X-Gm-Message-State: ALoCoQlwg8ywpnpK9u7zhJ5hmyF9dtf8V9QeeGpy9GK2WcV/fKogIPnV9dqnyF4W36WTTEO1Zqdq X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130805_003302_846457_A2C652E4 X-CRM114-Status: GOOD ( 26.38 ) X-Spam-Score: -2.6 (--) Cc: "dave.martin@linaro.org" , "linux-arm-kernel@lists.infradead.org" , "patches@linaro.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, 31 Jul 2013, Lorenzo Pieralisi wrote: > On Tue, Jul 23, 2013 at 04:31:27AM +0100, Nicolas Pitre wrote: > > Trying to support both the switcher and CPU hotplug at the same time > > is quickly becoming very complex due to ambiguous semantics. So let's > > simply veto any hotplug requests when the switcher is active for now. > > > > This restriction might be loosened eventually. > > > > Signed-off-by: Nicolas Pitre > > --- > > arch/arm/common/bL_switcher.c | 21 +++++++++++++++++++++ > > 1 file changed, 21 insertions(+) > > > > diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c > > index 704c4b4ef3..2fe3911601 100644 > > --- a/arch/arm/common/bL_switcher.c > > +++ b/arch/arm/common/bL_switcher.c > > @@ -528,6 +528,25 @@ static int __init bL_switcher_sysfs_init(void) > > > > #endif /* CONFIG_SYSFS */ > > > > +/* > > + * Veto any CPU hotplug operation while the switcher is active. > > + * We're just not ready to deal with that given the trickery involved. > > + */ > > +static int bL_switcher_hotplug_callback(struct notifier_block *nfb, > > + unsigned long action, void *hcpu) > > +{ > > + switch (action) { > > + case CPU_UP_PREPARE: > > + case CPU_DOWN_PREPARE: > > + if (bL_switcher_active) > > + return NOTIFY_BAD; > > This is a bit of a sledgehammer. It implies that S2R can't be implemented when > the switcher is active. Are we really sure that hotplug, given MCPM HW > CPUs awareness, is incompatible with the switcher as it stands ? > > What are the main issues that have to be tackled ? It's about semantics. Let's say the switcher pairs CPU0 with CPU2 and CPU1 with CPU3, effectively keeping only logical CPUS 0 and 1 active. Obviously, we must disallow hotplugging CPUs 2 and 3. But what if CPU0 is removed, and then the switcher is disabled? Should we bring up CPU2 or not? What if right before the disabling of the switcher, logical CPU0 was switched to CPU2? Etc. So I decided that there is no right answer, and maybe we shouldn't care that much about those semantic issues around the runtime disabling of the switcher. So I've replaced this patch with the following one: ----- >8 [PATCH] ARM: bL_switcher: filter CPU hotplug requests when the switcher is active Trying to support both the switcher and CPU hotplug at the same time is tricky due to ambiguous semantics. So let's at least prevent users from messing around with those logical CPUs the switcher has removed and those which were not active when the switcher was activated. Signed-off-by: Nicolas Pitre diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c index 0e4fb3e5e9..335ff76d4c 100644 --- a/arch/arm/common/bL_switcher.c +++ b/arch/arm/common/bL_switcher.c @@ -554,6 +554,26 @@ static int __init bL_switcher_sysfs_init(void) #endif /* CONFIG_SYSFS */ +/* + * Veto any CPU hotplug operation on those CPUs we've removed + * while the switcher is active. + * We're just not ready to deal with that given the trickery involved. + */ +static int bL_switcher_hotplug_callback(struct notifier_block *nfb, + unsigned long action, void *hcpu) +{ + if (bL_switcher_active) { + int pairing = bL_switcher_cpu_pairing[(unsigned long)hcpu]; + switch (action & 0xf) { + case CPU_UP_PREPARE: + case CPU_DOWN_PREPARE: + if (pairing == -1) + return NOTIFY_BAD; + } + } + return NOTIFY_DONE; +} + static bool no_bL_switcher; core_param(no_bL_switcher, no_bL_switcher, bool, 0644); @@ -566,6 +586,8 @@ static int __init bL_switcher_init(void) return -EINVAL; } + cpu_notifier(bL_switcher_hotplug_callback, 0); + if (!no_bL_switcher) { ret = bL_switcher_enable(); if (ret)