Re: [PATCH v4 0/5] Unify NUMA implementation between ARM64 & RISC-V

From: Palmer Dabbelt
Date: Thu Nov 05 2020 - 13:07:04 EST


On Mon, 05 Oct 2020 17:17:47 PDT (-0700), Atish Patra wrote:
This series attempts to move the ARM64 numa implementation to common
code so that RISC-V can leverage that as well instead of reimplementing
it again.

RISC-V specific bits are based on initial work done by Greentime Hu [1] but
modified to reuse the common implementation to avoid duplication.

[1] https://lkml.org/lkml/2020/1/10/233

This series has been tested on qemu with numa enabled for both RISC-V & ARM64.
It would be great if somebody can test it on numa capable ARM64 hardware platforms.
This patch series doesn't modify the maintainers list for the common code (arch_numa)
as I am not sure if somebody from ARM64 community or Greg should take up the
maintainership. Ganapatrao was the original author of the arm64 version.
I would be happy to update that in the next revision once it is decided.

# numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3
node 0 size: 486 MB
node 0 free: 470 MB
node 1 cpus: 4 5 6 7
node 1 size: 424 MB
node 1 free: 408 MB
node distances:
node 0 1
0: 10 20
1: 20 10
# numactl -show
policy: default
preferred node: current
physcpubind: 0 1 2 3 4 5 6 7
cpubind: 0 1
nodebind: 0 1
membind: 0 1

The patches are also available at
https://github.com/atishp04/linux/tree/5.10_numa_unified_v4

For RISC-V, the following qemu series is a pre-requisite(already available in upstream)
https://patchwork.kernel.org/project/qemu-devel/list/?series=303313

Testing:
RISC-V:
Tested in Qemu and 2 socket OmniXtend FPGA.

ARM64:
2 socket kunpeng920 (4 nodes around 250G a node)
Tested-by: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>

There may be some minor conflicts with Mike's cleanup series [2] depending on the
order in which these two series are being accepted. I can rebase on top his series
if required.

[2] https://lkml.org/lkml/2020/8/18/754

Changes from v3->v4:
1. Removed redundant duplicate header.
2. Added Reviewed-by tags.

Changes from v2->v3:
1. Added Acked-by/Reviewed-by tags.
2. Replaced asm/acpi.h with linux/acpi.h
3. Defined arch_acpi_numa_init as static.

Changes from v1->v2:
1. Replaced ARM64 specific compile time protection with ACPI specific ones.
2. Dropped common pcibus_to_node changes. Added required changes in RISC-V.
3. Fixed few typos.

Atish Patra (4):
numa: Move numa implementation to common code
arm64, numa: Change the numa init functions name to be generic
riscv: Separate memory init from paging init
riscv: Add numa support for riscv64 platform

Greentime Hu (1):
riscv: Add support pte_protnone and pmd_protnone if
CONFIG_NUMA_BALANCING

arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/numa.h | 45 +----------------
arch/arm64/kernel/acpi_numa.c | 13 -----
arch/arm64/mm/Makefile | 1 -
arch/arm64/mm/init.c | 4 +-
arch/riscv/Kconfig | 31 +++++++++++-
arch/riscv/include/asm/mmzone.h | 13 +++++
arch/riscv/include/asm/numa.h | 8 +++
arch/riscv/include/asm/pci.h | 14 ++++++
arch/riscv/include/asm/pgtable.h | 21 ++++++++
arch/riscv/kernel/setup.c | 11 ++++-
arch/riscv/kernel/smpboot.c | 12 ++++-
arch/riscv/mm/init.c | 10 +++-
drivers/base/Kconfig | 6 +++
drivers/base/Makefile | 1 +
.../mm/numa.c => drivers/base/arch_numa.c | 30 ++++++++++--
include/asm-generic/numa.h | 49 +++++++++++++++++++
17 files changed, 199 insertions(+), 71 deletions(-)
create mode 100644 arch/riscv/include/asm/mmzone.h
create mode 100644 arch/riscv/include/asm/numa.h
rename arch/arm64/mm/numa.c => drivers/base/arch_numa.c (95%)
create mode 100644 include/asm-generic/numa.h

Sorry it took me a while to get around to this, I had some work stuff to deal
with and have managed to get buried in email. This all looks fine to me, but
the way it's structured make it kind of hard to apply -- essentially I can't
take the first two without at least some Acks from the arm64 folks, and it
smells to me like it'd be better to have those go through the arm64 tree. The
RISC-V stuff isn't that heavywight, but I'd like it to at least land in my
for-next at some point as otherwise it'll be completely untested.

arm64 guys: do you want to try and do some sort of shared base tag sort of
thing for these, or do you want me to refactor this such that it adds the
generic stuff before removing the arm64 stuff so we can decouble that way?