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: Mon, 06 Apr 2015 17:47:50 +0000 [thread overview]
Message-ID: <5522C6C6.7050106@codeaurora.org> (raw)
In-Reply-To: <CANMBJr5-0dnVJ_gSBhOuyqmm7MnYLTKbTetezZnzucdxjNEVEA@mail.gmail.com>
On 04/06/15 10:19, Tyler Baker wrote:
> On 19 February 2015 at 14:14, Simon Horman <horms@verge.net.au> wrote:
>> On Wed, Feb 18, 2015 at 03:27:57PM -0800, Stephen Boyd wrote:
>>> 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.
>> I'm also happy to let RMK to decide what he thinks is best.
> Apologies for bringing up an older thread, but was this change ever
> picked up? I recently hit this issue when I was running the kselftest
> suite (specifically the cpu-hotplug test case) on the ARM boards from
> kernelci.org. I don't see it in -next so I've tested the core changes
> and confirmed it the fixes the cpu-hotplug behavior on platforms that
> do not support it.
No it hasn't gone anywhere. It would be good if Mark Rutland could ack
the patch, which I hope would give enough confidence to Russell that the
patch is good. Your tested-by would also be welcome. I'll go make the
bool change that Geert suggested and resend.
--
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: Mon, 06 Apr 2015 10:47:50 -0700 [thread overview]
Message-ID: <5522C6C6.7050106@codeaurora.org> (raw)
In-Reply-To: <CANMBJr5-0dnVJ_gSBhOuyqmm7MnYLTKbTetezZnzucdxjNEVEA@mail.gmail.com>
On 04/06/15 10:19, Tyler Baker wrote:
> On 19 February 2015 at 14:14, Simon Horman <horms@verge.net.au> wrote:
>> On Wed, Feb 18, 2015 at 03:27:57PM -0800, Stephen Boyd wrote:
>>> 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.
>> I'm also happy to let RMK to decide what he thinks is best.
> Apologies for bringing up an older thread, but was this change ever
> picked up? I recently hit this issue when I was running the kselftest
> suite (specifically the cpu-hotplug test case) on the ARM boards from
> kernelci.org. I don't see it in -next so I've tested the core changes
> and confirmed it the fixes the cpu-hotplug behavior on platforms that
> do not support it.
No it hasn't gone anywhere. It would be good if Mark Rutland could ack
the patch, which I hope would give enough confidence to Russell that the
patch is good. Your tested-by would also be welcome. I'll go make the
bool change that Geert suggested and resend.
--
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: Tyler Baker <tyler.baker@linaro.org>,
Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>,
Nicolas Pitre <nico@linaro.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
Magnus Damm <magnus.damm@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Dave Martin <Dave.Martin@arm.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Simon Horman <horms@verge.net.au>,
"Kevin's boot bot" <khilman@kernel.org>
Subject: Re: [PATCH v3] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable
Date: Mon, 06 Apr 2015 10:47:50 -0700 [thread overview]
Message-ID: <5522C6C6.7050106@codeaurora.org> (raw)
In-Reply-To: <CANMBJr5-0dnVJ_gSBhOuyqmm7MnYLTKbTetezZnzucdxjNEVEA@mail.gmail.com>
On 04/06/15 10:19, Tyler Baker wrote:
> On 19 February 2015 at 14:14, Simon Horman <horms@verge.net.au> wrote:
>> On Wed, Feb 18, 2015 at 03:27:57PM -0800, Stephen Boyd wrote:
>>> 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.
>> I'm also happy to let RMK to decide what he thinks is best.
> Apologies for bringing up an older thread, but was this change ever
> picked up? I recently hit this issue when I was running the kselftest
> suite (specifically the cpu-hotplug test case) on the ARM boards from
> kernelci.org. I don't see it in -next so I've tested the core changes
> and confirmed it the fixes the cpu-hotplug behavior on platforms that
> do not support it.
No it hasn't gone anywhere. It would be good if Mark Rutland could ack
the patch, which I hope would give enough confidence to Russell that the
patch is good. Your tested-by would also be welcome. I'll go make the
bool change that Geert suggested and resend.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2015-04-06 17:47 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
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 [this message]
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=5522C6C6.7050106@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.