[PATCH 00/21] Initial cleanups for vCPU hotplug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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(-)

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!




[Index of Archives]     [Linux Kernel]     [Sparc Linux]     [DCCP]     [Linux ARM]     [Yosemite News]     [Linux SCSI]     [Linux x86_64]     [Linux for Ham Radio]

  Powered by Linux