From: Stephen Boyd <sboyd@codeaurora.org>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable
Date: Wed, 18 Feb 2015 23:27:57 +0000 [thread overview]
Message-ID: <54E51FFD.7080506@codeaurora.org> (raw)
In-Reply-To: <20150218222731.GC24177@verge.net.au>
On 02/18/15 14:27, Simon Horman wrote:
> On Fri, Feb 13, 2015 at 04:42:54PM -0800, Stephen Boyd wrote:
>> Writes to /sys/.../cpuX/online fail if we determine the platform
>> doesn't support hotplug for that CPU. Furthermore, if the cpu_die
>> op isn't specified the system hangs when we try to offline a CPU
>> and it comes right back online unexpectedly. Let's figure this
>> stuff out before we make the sysfs nodes so that the online file
>> doesn't even exist if it isn't (at least sometimes) possible to
>> hotplug the CPU.
>>
>> Add a new cpu_can_disable op and repoint all cpu_disable
>> implementations at it because all current users use the op to
>> indicate if a CPU can be hotplugged or not in a static fashion.
>> With PSCI we may need to introduce a cpu_disable op so that the
>> secure OS can be migrated off the CPU we're trying to hotplug.
>> In this case, the cpu_can_disable op will indicate that all CPUs
>> are hotpluggable by returning 1, but the cpu_disable op will make
>> a PSCI migration call and occasionally fail, denying the hotplug
>> of a CPU. This shouldn't be any worse than x86 where we may
>> indicate that all CPUs are hotpluggable but occasionally we can't
>> offline a CPU due to check_irq_vectors_for_cpu_disable() failing
>> to find a CPU to move vectors to.
>>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Nicolas Pitre <nico@linaro.org>
>> Cc: Dave Martin <Dave.Martin@arm.com>
>> Cc: Simon Horman <horms@verge.net.au>
>> Cc: Magnus Damm <magnus.damm@gmail.com>
>> Cc: <linux-sh@vger.kernel.org>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>>
>> Changes since v2:
>> * Left cpu_disable op in place
>> * Split out shmobile function deletion
>>
>> arch/arm/common/mcpm_platsmp.c | 12 ++++--------
>> arch/arm/include/asm/smp.h | 10 ++++++++++
>> arch/arm/kernel/setup.c | 2 +-
>> arch/arm/kernel/smp.c | 15 ++++++++++++++-
>> arch/arm/mach-shmobile/common.h | 2 +-
>> arch/arm/mach-shmobile/platsmp.c | 4 ++--
>> arch/arm/mach-shmobile/smp-r8a7790.c | 2 +-
>> arch/arm/mach-shmobile/smp-r8a7791.c | 2 +-
>> arch/arm/mach-shmobile/smp-sh73a0.c | 2 +-
>> 9 files changed, 35 insertions(+), 16 deletions(-)
> I think it would make sense to separate the ARM-core changes
> from the mach-shmobile integration changes.
Are you saying two (three?) patches to add the op, and then move over
each struct smp_operations? It's all going through rmk's tree so I'll
leave that up to him.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable
Date: Wed, 18 Feb 2015 15:27:57 -0800 [thread overview]
Message-ID: <54E51FFD.7080506@codeaurora.org> (raw)
In-Reply-To: <20150218222731.GC24177@verge.net.au>
On 02/18/15 14:27, Simon Horman wrote:
> On Fri, Feb 13, 2015 at 04:42:54PM -0800, Stephen Boyd wrote:
>> Writes to /sys/.../cpuX/online fail if we determine the platform
>> doesn't support hotplug for that CPU. Furthermore, if the cpu_die
>> op isn't specified the system hangs when we try to offline a CPU
>> and it comes right back online unexpectedly. Let's figure this
>> stuff out before we make the sysfs nodes so that the online file
>> doesn't even exist if it isn't (at least sometimes) possible to
>> hotplug the CPU.
>>
>> Add a new cpu_can_disable op and repoint all cpu_disable
>> implementations at it because all current users use the op to
>> indicate if a CPU can be hotplugged or not in a static fashion.
>> With PSCI we may need to introduce a cpu_disable op so that the
>> secure OS can be migrated off the CPU we're trying to hotplug.
>> In this case, the cpu_can_disable op will indicate that all CPUs
>> are hotpluggable by returning 1, but the cpu_disable op will make
>> a PSCI migration call and occasionally fail, denying the hotplug
>> of a CPU. This shouldn't be any worse than x86 where we may
>> indicate that all CPUs are hotpluggable but occasionally we can't
>> offline a CPU due to check_irq_vectors_for_cpu_disable() failing
>> to find a CPU to move vectors to.
>>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Nicolas Pitre <nico@linaro.org>
>> Cc: Dave Martin <Dave.Martin@arm.com>
>> Cc: Simon Horman <horms@verge.net.au>
>> Cc: Magnus Damm <magnus.damm@gmail.com>
>> Cc: <linux-sh@vger.kernel.org>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>>
>> Changes since v2:
>> * Left cpu_disable op in place
>> * Split out shmobile function deletion
>>
>> arch/arm/common/mcpm_platsmp.c | 12 ++++--------
>> arch/arm/include/asm/smp.h | 10 ++++++++++
>> arch/arm/kernel/setup.c | 2 +-
>> arch/arm/kernel/smp.c | 15 ++++++++++++++-
>> arch/arm/mach-shmobile/common.h | 2 +-
>> arch/arm/mach-shmobile/platsmp.c | 4 ++--
>> arch/arm/mach-shmobile/smp-r8a7790.c | 2 +-
>> arch/arm/mach-shmobile/smp-r8a7791.c | 2 +-
>> arch/arm/mach-shmobile/smp-sh73a0.c | 2 +-
>> 9 files changed, 35 insertions(+), 16 deletions(-)
> I think it would make sense to separate the ARM-core changes
> from the mach-shmobile integration changes.
Are you saying two (three?) patches to add the op, and then move over
each struct smp_operations? It's all going through rmk's tree so I'll
leave that up to him.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@codeaurora.org>
To: Simon Horman <horms@verge.net.au>
Cc: Russell King <linux@arm.linux.org.uk>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Mark Rutland <mark.rutland@arm.com>,
Nicolas Pitre <nico@linaro.org>,
Dave Martin <Dave.Martin@arm.com>,
Magnus Damm <magnus.damm@gmail.com>,
linux-sh@vger.kernel.org
Subject: Re: [PATCH v3] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable
Date: Wed, 18 Feb 2015 15:27:57 -0800 [thread overview]
Message-ID: <54E51FFD.7080506@codeaurora.org> (raw)
In-Reply-To: <20150218222731.GC24177@verge.net.au>
On 02/18/15 14:27, Simon Horman wrote:
> On Fri, Feb 13, 2015 at 04:42:54PM -0800, Stephen Boyd wrote:
>> Writes to /sys/.../cpuX/online fail if we determine the platform
>> doesn't support hotplug for that CPU. Furthermore, if the cpu_die
>> op isn't specified the system hangs when we try to offline a CPU
>> and it comes right back online unexpectedly. Let's figure this
>> stuff out before we make the sysfs nodes so that the online file
>> doesn't even exist if it isn't (at least sometimes) possible to
>> hotplug the CPU.
>>
>> Add a new cpu_can_disable op and repoint all cpu_disable
>> implementations at it because all current users use the op to
>> indicate if a CPU can be hotplugged or not in a static fashion.
>> With PSCI we may need to introduce a cpu_disable op so that the
>> secure OS can be migrated off the CPU we're trying to hotplug.
>> In this case, the cpu_can_disable op will indicate that all CPUs
>> are hotpluggable by returning 1, but the cpu_disable op will make
>> a PSCI migration call and occasionally fail, denying the hotplug
>> of a CPU. This shouldn't be any worse than x86 where we may
>> indicate that all CPUs are hotpluggable but occasionally we can't
>> offline a CPU due to check_irq_vectors_for_cpu_disable() failing
>> to find a CPU to move vectors to.
>>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Nicolas Pitre <nico@linaro.org>
>> Cc: Dave Martin <Dave.Martin@arm.com>
>> Cc: Simon Horman <horms@verge.net.au>
>> Cc: Magnus Damm <magnus.damm@gmail.com>
>> Cc: <linux-sh@vger.kernel.org>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>>
>> Changes since v2:
>> * Left cpu_disable op in place
>> * Split out shmobile function deletion
>>
>> arch/arm/common/mcpm_platsmp.c | 12 ++++--------
>> arch/arm/include/asm/smp.h | 10 ++++++++++
>> arch/arm/kernel/setup.c | 2 +-
>> arch/arm/kernel/smp.c | 15 ++++++++++++++-
>> arch/arm/mach-shmobile/common.h | 2 +-
>> arch/arm/mach-shmobile/platsmp.c | 4 ++--
>> arch/arm/mach-shmobile/smp-r8a7790.c | 2 +-
>> arch/arm/mach-shmobile/smp-r8a7791.c | 2 +-
>> arch/arm/mach-shmobile/smp-sh73a0.c | 2 +-
>> 9 files changed, 35 insertions(+), 16 deletions(-)
> I think it would make sense to separate the ARM-core changes
> from the mach-shmobile integration changes.
Are you saying two (three?) patches to add the op, and then move over
each struct smp_operations? It's all going through rmk's tree so I'll
leave that up to him.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2015-02-18 23:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-14 0:42 [PATCH v3] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable Stephen Boyd
2015-02-14 0:42 ` Stephen Boyd
2015-02-14 0:42 ` Stephen Boyd
2015-02-16 9:03 ` Geert Uytterhoeven
2015-02-16 9:03 ` Geert Uytterhoeven
2015-02-16 9:03 ` Geert Uytterhoeven
2015-02-18 22:27 ` Simon Horman
2015-02-18 22:27 ` Simon Horman
2015-02-18 22:27 ` Simon Horman
2015-02-18 23:27 ` Stephen Boyd [this message]
2015-02-18 23:27 ` Stephen Boyd
2015-02-18 23:27 ` Stephen Boyd
2015-02-19 22:14 ` Simon Horman
2015-02-19 22:14 ` Simon Horman
2015-02-19 22:14 ` Simon Horman
2015-04-06 17:19 ` Tyler Baker
2015-04-06 17:19 ` Tyler Baker
2015-04-06 17:19 ` Tyler Baker
2015-04-06 17:47 ` Stephen Boyd
2015-04-06 17:47 ` Stephen Boyd
2015-04-06 17:47 ` Stephen Boyd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54E51FFD.7080506@codeaurora.org \
--to=sboyd@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.