[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1608261207510.5714@nanos>
Date: Fri, 26 Aug 2016 12:09:38 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Will Deacon <will.deacon@....com>
cc: James Morse <james.morse@....com>, linux-kernel@...r.kernel.org,
Mark Rutland <mark.rutland@....com>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
linux-pm@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>,
"Rafael J . Wysocki" <rjw@...ysocki.net>,
Catalin Marinas <catalin.marinas@....com>,
Ingo Molnar <mingo@...nel.org>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v5 1/3] cpu/hotplug: Allow suspend/resume CPU to be
specified
On Fri, 26 Aug 2016, Will Deacon wrote:
> On Wed, Aug 17, 2016 at 01:50:25PM +0100, James Morse wrote:
> > disable_nonboot_cpus() assumes that the lowest numbered online CPU is
> > the boot CPU, and that this is the correct CPU to run any power
> > management code on.
> >
> > On x86 this is always correct, as CPU0 cannot (easily) by taken offline.
> >
> > On arm64 CPU0 can be taken offline. For hibernate/resume this means we
> > may hibernate on a CPU other than CPU0. If the system is rebooted with
> > kexec 'CPU0' will be assigned to a different physical CPU. This
> > complicates hibernate/resume as now we can't trust the CPU numbers.
> > Arch code can find the correct physical CPU, and ensure it is online
> > before resume from hibernate begins, but also needs to influence
> > disable_nonboot_cpus()s choice of CPU.
> >
> > Rename disable_nonboot_cpus() as freeze_secondary_cpus() and add an
> > argument indicating which CPU should be left standing. Follow the logic
> > in migrate_to_reboot_cpu() to use the lowest numbered online CPU if the
> > requested CPU is not online.
> > Add disable_nonboot_cpus() as an inline function that has the existing
> > behaviour.
> >
> > Signed-off-by: James Morse <james.morse@....com>
> > Cc: Rafael J. Wysocki <rjw@...ysocki.net>
> > ---
> > An alternative is to provide two functions calling a common function,
> > but this would mean spilling the cpu_maps_update_begin() into these two.
> >
> > include/linux/cpu.h | 6 +++++-
> > kernel/cpu.c | 9 +++++----
> > 2 files changed, 10 insertions(+), 5 deletions(-)
>
> Thomas, does this look ok to you? If so, would you prefer to merge this
> series via -tip, or have us take this one via the arm64 tree?
You can take it via ARM64. It's not conflicting with the stuff I have in the
pipeline.
Reviewed-by: Thomas Gleixner <tglx@...utronix.de>
Powered by blists - more mailing lists