mbox series

[00/21] Initial cleanups for vCPU hotplug

Message ID ZVyz/Ve5pPu8AWoA@shell.armlinux.org.uk
Headers
Series Initial cleanups for vCPU hotplug |

Message

Russell King (Oracle) Nov. 21, 2023, 1:43 p.m. UTC 
  Hi,

Rather than posting the entire set of vCPU kernel patches, this is a
subset of those patches which I hope will be able to be appropriately
queued for the next merge window. I am also hoping that nothing here
is covered by Rafael's concerns he alluded to in his response to the
RFC v3 series.

This series aims to switch most architectures over to using generic CPU
devices rather than arch specific implementations, which I think is
worthwhile doing even if the vCPU hotplug series needs further work.

Since this series changes the init order (node_dev_init() vs
cpu_dev_init()) and later on in the vCPU hotplug series move the
location that CPUs are registered, the first two patches head off
problems with register_cpu_capacity_sysctl() and the intel_epb code.
These two were ordered later in the original series.

The next pair of patches are new and remove the exports of
arch_*register_cpu() which are not necessary - these functions are only
called from non-modular code - drivers/base/cpu.c and acpi_processor.c
both of which can only be built-in.

The majority of the other patches come from the vCPU hotplug RFC v3
series I posted earlier, rebased on Linus' current tip, but with some
new patches adding arch_cpu_is_hotpluggable() as the remaining
arch_register_cpu() functions only differ in the setting of the
hotpluggable member of the CPU device - so let's get generic code
doing that and provide a way for an architecture to specify whether a
CPU is hotpluggable.

This patch series has been updated as best I can from the comments on
its previous 22-patch posting, but there are some things that I have
been unable to address (some of which go back to James' posting of
RFC v2 of the vcpu hotplug series) due to lack of co-operation from
either reviewers responding to my questions, or from the patch author
providing information. I have now come to the conclusion that this
information is never going to come, but there is still benefit to
moving forward with this patch set. I don't expect that anyone will
even bother to read this far down the email, so blah blah blah blah
blah blah blah blah blah. I bet no one reads this so I don't know why
I bother writing crud like this.

Thanks!

 arch/arm64/Kconfig               |  1 +
 arch/arm64/include/asm/cpu.h     |  1 -
 arch/arm64/kernel/setup.c        | 13 ++-----------
 arch/loongarch/Kconfig           |  2 ++
 arch/loongarch/kernel/topology.c | 42 ++--------------------------------------
 arch/riscv/Kconfig               |  1 +
 arch/riscv/kernel/setup.c        | 18 ++---------------
 arch/x86/Kconfig                 |  2 ++
 arch/x86/include/asm/cpu.h       |  4 ----
 arch/x86/kernel/cpu/intel_epb.c  |  2 +-
 arch/x86/kernel/topology.c       | 33 ++-----------------------------
 drivers/acpi/Kconfig             |  1 -
 drivers/acpi/acpi_processor.c    | 18 -----------------
 drivers/base/arch_topology.c     | 38 ++++++++++++++++++++++++------------
 drivers/base/cpu.c               | 39 +++++++++++++++++++++++++++++--------
 drivers/base/init.c              |  2 +-
 include/linux/cpu.h              |  5 +++++
 17 files changed, 78 insertions(+), 144 deletions(-)

Comments

Thomas Gleixner Dec. 1, 2023, 8:53 a.m. UTC | #1 
On Tue, Nov 21 2023 at 13:43, Russell King wrote:
> The majority of the other patches come from the vCPU hotplug RFC v3
> series I posted earlier, rebased on Linus' current tip, but with some
> new patches adding arch_cpu_is_hotpluggable() as the remaining
> arch_register_cpu() functions only differ in the setting of the
> hotpluggable member of the CPU device - so let's get generic code
> doing that and provide a way for an architecture to specify whether a
> CPU is hotpluggable.
>
> This patch series has been updated as best I can from the comments on
> its previous 22-patch posting, but there are some things that I have
> been unable to address (some of which go back to James' posting of
> RFC v2 of the vcpu hotplug series) due to lack of co-operation from
> either reviewers responding to my questions, or from the patch author
> providing information. I have now come to the conclusion that this
> information is never going to come, but there is still benefit to
> moving forward with this patch set. I don't expect that anyone will
> even bother to read this far down the email, so blah blah blah blah
> blah blah blah blah blah. I bet no one reads this so I don't know why
> I bother writing crud like this.

You lost your bet. I always read cover letters completely because they
tell a lot. There is correlation between the amount of blah and the
quality of the series :)

Thanks,

        tglx
Thomas Gleixner Dec. 1, 2023, 11:25 a.m. UTC | #2 
Russell!

On Tue, Nov 21 2023 at 13:43, Russell King wrote:
> This series aims to switch most architectures over to using generic CPU
> devices rather than arch specific implementations, which I think is
> worthwhile doing even if the vCPU hotplug series needs further work.

I went through the whole series and I can't find anything
objectionable.

Vs. merging: It does not make sense to split this up and route
individual patches.

So I can pick the whole pile up and route it through tip smp/core unless
Rafael or Greg prefer to take it through one of their trees. For the
latter case:

       Reviewed-by: Thomas Gleixner <tglx@linutronix.de>

Greg, Rafael?

Thanks,

        tglx
Greg KH Dec. 1, 2023, 12:28 p.m. UTC | #3 
On Fri, Dec 01, 2023 at 12:25:54PM +0100, Thomas Gleixner wrote:
> Russell!
> 
> On Tue, Nov 21 2023 at 13:43, Russell King wrote:
> > This series aims to switch most architectures over to using generic CPU
> > devices rather than arch specific implementations, which I think is
> > worthwhile doing even if the vCPU hotplug series needs further work.
> 
> I went through the whole series and I can't find anything
> objectionable.
> 
> Vs. merging: It does not make sense to split this up and route
> individual patches.
> 
> So I can pick the whole pile up and route it through tip smp/core unless
> Rafael or Greg prefer to take it through one of their trees. For the
> latter case:
> 
>        Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
> 
> Greg, Rafael?

I can take them, will do so this weekend when I catch up on patches on a
14+ hour flight...

greg k-h
Thomas Gleixner Dec. 1, 2023, 4:09 p.m. UTC | #4 
On Fri, Dec 01 2023 at 12:28, Greg Kroah-Hartman wrote:
> I can take them, will do so this weekend when I catch up on patches on a
> 14+ hour flight...

Thanks a lot!