From: Andrew Jones <ajones@ventanamicro.com>
To: Gavin Shan <gshan@redhat.com>
Cc: qemu-arm@nongnu.org, qemu-devel@nongnu.org,
qemu-riscv@nongnu.org, rad@semihalf.com,
peter.maydell@linaro.org, quic_llindhol@quicinc.com,
eduardo@habkost.net, marcel.apfelbaum@gmail.com,
philmd@linaro.org, wangyanan55@huawei.com, palmer@dabbelt.com,
alistair.francis@wdc.com, bin.meng@windriver.com,
thuth@redhat.com, lvivier@redhat.com, pbonzini@redhat.com,
imammedo@redhat.com, yihyu@redhat.com, shan.gavin@gmail.com
Subject: Re: [PATCH v2 0/4] NUMA: Apply socket-NUMA-node boundary for aarch64 and RiscV machines
Date: Thu, 23 Feb 2023 13:25:15 +0100 [thread overview]
Message-ID: <20230223122515.mzsubkwv3mgrcvhl@orel> (raw)
In-Reply-To: <20230223081401.248835-1-gshan@redhat.com>
On Thu, Feb 23, 2023 at 04:13:57PM +0800, Gavin Shan wrote:
> For arm64 and RiscV architecture, the driver (/base/arch_topology.c) is
> used to populate the CPU topology in the Linux guest. It's required that
> the CPUs in one socket can't span mutiple NUMA nodes. Otherwise, the Linux
> scheduling domain can't be sorted out, as the following warning message
> indicates. To avoid the unexpected confusion, this series attempts to
> rejects such kind of insane configurations.
Hi Gavin,
I'm not sure 'insane' is the right word, maybe 'irregular'. I've never
seen, and don't really expect to find, specifications stating that arm
and/or riscv must have 1:1 mappings for numa nodes and sockets. But, as
QEMU machine types can choose certain configurations to support, if
everyone is in agreement to restrict sbsa-ref and arm/riscv virt to 1:1
mappings, then why not. However, I suggest stating that this is simply a
choice being made for these boards, since the expectation of needing
"irregular" configurations is low. We should not be trying to use Linux
assumptions as rationale, since other OSes may cope better with irregular
configurations.
Also, I suggest adding a comment to the boards, which adopt this
restriction, which explains that it's only a platform choice, not
something specified by the architecture.
Thanks,
drew
>
> -smp 6,maxcpus=6,sockets=2,clusters=1,cores=3,threads=1 \
> -numa node,nodeid=0,cpus=0-1,memdev=ram0 \
> -numa node,nodeid=1,cpus=2-3,memdev=ram1 \
> -numa node,nodeid=2,cpus=4-5,memdev=ram2 \
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at kernel/sched/topology.c:2271 build_sched_domains+0x284/0x910
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-268.el9.aarch64 #1
> pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : build_sched_domains+0x284/0x910
> lr : build_sched_domains+0x184/0x910
> sp : ffff80000804bd50
> x29: ffff80000804bd50 x28: 0000000000000002 x27: 0000000000000000
> x26: ffff800009cf9a80 x25: 0000000000000000 x24: ffff800009cbf840
> x23: ffff000080325000 x22: ffff0000005df800 x21: ffff80000a4ce508
> x20: 0000000000000000 x19: ffff000080324440 x18: 0000000000000014
> x17: 00000000388925c0 x16: 000000005386a066 x15: 000000009c10cc2e
> x14: 00000000000001c0 x13: 0000000000000001 x12: ffff00007fffb1a0
> x11: ffff00007fffb180 x10: ffff80000a4ce508 x9 : 0000000000000041
> x8 : ffff80000a4ce500 x7 : ffff80000a4cf920 x6 : 0000000000000001
> x5 : 0000000000000001 x4 : 0000000000000007 x3 : 0000000000000002
> x2 : 0000000000001000 x1 : ffff80000a4cf928 x0 : 0000000000000001
> Call trace:
> build_sched_domains+0x284/0x910
> sched_init_domains+0xac/0xe0
> sched_init_smp+0x48/0xc8
> kernel_init_freeable+0x140/0x1ac
> kernel_init+0x28/0x140
> ret_from_fork+0x10/0x20
>
> PATCH[1] Improves numa/test for aarch64 to follow socket-to-NUMA-node boundary
> PATCH[2] Validate the configuration if required in the NUMA subsystem
> PATCH[3] Enable the validation for aarch64 machines
> PATCH[4] Enable the validation for RiscV machines
>
> v1: https://lists.nongnu.org/archive/html/qemu-arm/2023-02/msg00886.html
>
> Changelog
> =========
> v2:
> * Fix socket-NUMA-node boundary issues in qtests/numa-test (Gavin)
> * Add helper set_numa_socket_boundary() and validate the
> boundary in the generic path (Philippe)
>
> Gavin Shan (4):
> qtest/numa-test: Follow socket-NUMA-node boundary for aarch64
> numa: Validate socket and NUMA node boundary if required
> hw/arm: Validate socket and NUMA node boundary
> hw/riscv: Validate socket and NUMA node boundary
>
> hw/arm/sbsa-ref.c | 2 ++
> hw/arm/virt.c | 2 ++
> hw/core/machine.c | 34 ++++++++++++++++++++++++++++++++++
> hw/core/numa.c | 7 +++++++
> hw/riscv/spike.c | 1 +
> hw/riscv/virt.c | 1 +
> include/sysemu/numa.h | 4 ++++
> tests/qtest/numa-test.c | 13 ++++++++++---
> 8 files changed, 61 insertions(+), 3 deletions(-)
>
> --
> 2.23.0
>
>
next prev parent reply other threads:[~2023-02-23 12:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-23 8:13 [PATCH v2 0/4] NUMA: Apply socket-NUMA-node boundary for aarch64 and RiscV machines Gavin Shan
2023-02-23 8:13 ` [PATCH v2 1/4] qtest/numa-test: Follow socket-NUMA-node boundary for aarch64 Gavin Shan
2023-02-23 8:13 ` [PATCH v2 2/4] numa: Validate socket and NUMA node boundary if required Gavin Shan
2023-02-23 9:05 ` Philippe Mathieu-Daudé
2023-02-23 10:27 ` Gavin Shan
2023-02-23 8:14 ` [PATCH v2 3/4] hw/arm: Validate socket and NUMA node boundary Gavin Shan
2023-02-23 8:14 ` [PATCH v2 4/4] hw/riscv: " Gavin Shan
2023-02-23 12:25 ` Andrew Jones [this message]
2023-02-24 7:20 ` [PATCH v2 0/4] NUMA: Apply socket-NUMA-node boundary for aarch64 and RiscV machines Gavin Shan
2023-02-23 12:57 ` Daniel P. Berrangé
2023-02-24 5:47 ` Gavin Shan
2023-02-23 13:18 ` Daniel Henrique Barboza
2023-02-24 7:09 ` Gavin Shan
2023-02-24 9:26 ` Daniel Henrique Barboza
2023-02-24 10:16 ` Gavin Shan
2023-02-24 10:39 ` Andrew Jones
2023-02-24 14:20 ` Igor Mammedov
2023-02-25 0:05 ` Gavin Shan
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=20230223122515.mzsubkwv3mgrcvhl@orel \
--to=ajones@ventanamicro.com \
--cc=alistair.francis@wdc.com \
--cc=bin.meng@windriver.com \
--cc=eduardo@habkost.net \
--cc=gshan@redhat.com \
--cc=imammedo@redhat.com \
--cc=lvivier@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=palmer@dabbelt.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=quic_llindhol@quicinc.com \
--cc=rad@semihalf.com \
--cc=shan.gavin@gmail.com \
--cc=thuth@redhat.com \
--cc=wangyanan55@huawei.com \
--cc=yihyu@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).