From: Greg Kurz <groug@kaod.org>
To: Daniel Henrique Barboza <danielhb413@gmail.com>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org, david@gibson.dropbear.id.au
Subject: Re: [PATCH v6 2/6] spapr_numa.c: scrap 'legacy_numa' concept
Date: Tue, 14 Sep 2021 10:34:06 +0200 [thread overview]
Message-ID: <20210914103406.7d38f446@bahia.huguette> (raw)
In-Reply-To: <20210910195539.797170-3-danielhb413@gmail.com>
On Fri, 10 Sep 2021 16:55:35 -0300
Daniel Henrique Barboza <danielhb413@gmail.com> wrote:
> When first introduced, 'legacy_numa' was a way to refer to guests that
> either wouldn't be affected by associativity domain calculations, namely
> the ones with only 1 NUMA node, and pre 5.2 guests that shouldn't be
> affected by it because it would be an userspace change. Calling these
> cases 'legacy_numa' was a convenient way to label these cases.
>
> We're about to introduce a new NUMA affinity, FORM2, and this concept
> of 'legacy_numa' is now a bit misleading because, although it is called
> 'legacy' it is in fact a FORM1 exclusive contraint.
>
> This patch removes spapr_machine_using_legacy_numa() and open code the
> conditions in each caller. While we're at it, move the chunk inside
> spapr_numa_FORM1_affinity_init() that sets all numa_assoc_array domains
> with 'node_id' to spapr_numa_define_FORM1_domains(). This chunk was
> being executed if !pre_5_2_numa_associativity and num_nodes => 1, the
> same conditions in which spapr_numa_define_FORM1_domains() is called
> shortly after.
>
Those are definitely improvements. Just one question, see below.
> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
> ---
> hw/ppc/spapr_numa.c | 46 +++++++++++++++++++--------------------------
> 1 file changed, 19 insertions(+), 27 deletions(-)
>
> diff --git a/hw/ppc/spapr_numa.c b/hw/ppc/spapr_numa.c
> index 786def7c73..fb6059550f 100644
> --- a/hw/ppc/spapr_numa.c
> +++ b/hw/ppc/spapr_numa.c
> @@ -19,15 +19,6 @@
> /* Moved from hw/ppc/spapr_pci_nvlink2.c */
> #define SPAPR_GPU_NUMA_ID (cpu_to_be32(1))
>
> -static bool spapr_machine_using_legacy_numa(SpaprMachineState *spapr)
> -{
> - MachineState *machine = MACHINE(spapr);
> - SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(machine);
> -
> - return smc->pre_5_2_numa_associativity ||
> - machine->numa_state->num_nodes <= 1;
> -}
> -
> static bool spapr_numa_is_symmetrical(MachineState *ms)
> {
> int src, dst;
> @@ -97,7 +88,18 @@ static void spapr_numa_define_FORM1_domains(SpaprMachineState *spapr)
> MachineState *ms = MACHINE(spapr);
> NodeInfo *numa_info = ms->numa_state->nodes;
> int nb_numa_nodes = ms->numa_state->num_nodes;
> - int src, dst, i;
> + int src, dst, i, j;
> +
> + /*
> + * Fill all associativity domains of non-zero NUMA nodes with
> + * node_id. This is required because the default value (0) is
> + * considered a match with associativity domains of node 0.
> + */
> + for (i = 1; i < nb_numa_nodes; i++) {
> + for (j = 1; j < MAX_DISTANCE_REF_POINTS; j++) {
> + spapr->numa_assoc_array[i][j] = cpu_to_be32(i);
> + }
> + }
>
> for (src = 0; src < nb_numa_nodes; src++) {
> for (dst = src; dst < nb_numa_nodes; dst++) {
> @@ -164,7 +166,6 @@ static void spapr_numa_FORM1_affinity_init(SpaprMachineState *spapr,
> SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(spapr);
> int nb_numa_nodes = machine->numa_state->num_nodes;
> int i, j, max_nodes_with_gpus;
> - bool using_legacy_numa = spapr_machine_using_legacy_numa(spapr);
>
> /*
> * For all associativity arrays: first position is the size,
> @@ -178,17 +179,6 @@ static void spapr_numa_FORM1_affinity_init(SpaprMachineState *spapr,
> for (i = 0; i < nb_numa_nodes; i++) {
> spapr->numa_assoc_array[i][0] = cpu_to_be32(MAX_DISTANCE_REF_POINTS);
> spapr->numa_assoc_array[i][MAX_DISTANCE_REF_POINTS] = cpu_to_be32(i);
> -
> - /*
> - * Fill all associativity domains of non-zero NUMA nodes with
> - * node_id. This is required because the default value (0) is
> - * considered a match with associativity domains of node 0.
> - */
> - if (!using_legacy_numa && i != 0) {
> - for (j = 1; j < MAX_DISTANCE_REF_POINTS; j++) {
> - spapr->numa_assoc_array[i][j] = cpu_to_be32(i);
> - }
> - }
> }
>
> /*
> @@ -214,11 +204,13 @@ static void spapr_numa_FORM1_affinity_init(SpaprMachineState *spapr,
> }
>
> /*
> - * Legacy NUMA guests (pseries-5.1 and older, or guests with only
> - * 1 NUMA node) will not benefit from anything we're going to do
> - * after this point.
> + * Guests pseries-5.1 and older uses zeroed associativity domains,
> + * i.e. no domain definition based on NUMA distance input.
> + *
> + * Same thing with guests that have only one NUMA node.
> */
> - if (using_legacy_numa) {
> + if (smc->pre_5_2_numa_associativity ||
> + machine->numa_state->num_nodes <= 1) {
> return;
> }
>
> @@ -334,7 +326,7 @@ static void spapr_numa_FORM1_write_rtas_dt(SpaprMachineState *spapr,
> cpu_to_be32(maxdomain)
> };
>
> - if (spapr_machine_using_legacy_numa(spapr)) {
> + if (smc->pre_5_2_numa_associativity) {
This doesn't check the number of NUMA nodes and thus changes behavior,
or am I missing something ?
Rest looks good though so if you add the missing check or provide a
justification, feel free to add:
Reviewed-by: Greg Kurz <groug@kaod.org>
> uint32_t legacy_refpoints[] = {
> cpu_to_be32(0x4),
> cpu_to_be32(0x4),
next prev parent reply other threads:[~2021-09-14 8:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-10 19:55 [PATCH v6 0/6] pSeries FORM2 affinity support Daniel Henrique Barboza
2021-09-10 19:55 ` [PATCH v6 1/6] spapr_numa.c: split FORM1 code into helpers Daniel Henrique Barboza
2021-09-14 8:23 ` Greg Kurz
2021-09-10 19:55 ` [PATCH v6 2/6] spapr_numa.c: scrap 'legacy_numa' concept Daniel Henrique Barboza
2021-09-14 8:34 ` Greg Kurz [this message]
2021-09-10 19:55 ` [PATCH v6 3/6] spapr: introduce spapr_numa_associativity_reset() Daniel Henrique Barboza
2021-09-14 11:55 ` Greg Kurz
2021-09-14 19:58 ` Daniel Henrique Barboza
2021-09-16 1:32 ` Daniel Henrique Barboza
2021-09-16 17:31 ` Greg Kurz
2021-09-10 19:55 ` [PATCH v6 4/6] spapr_numa.c: parametrize FORM1 macros Daniel Henrique Barboza
2021-09-14 12:10 ` Greg Kurz
2021-09-10 19:55 ` [PATCH v6 5/6] spapr: move FORM1 verifications to post CAS Daniel Henrique Barboza
2021-09-14 12:26 ` Greg Kurz
2021-09-10 19:55 ` [PATCH v6 6/6] spapr_numa.c: FORM2 NUMA affinity support Daniel Henrique Barboza
2021-09-14 12:58 ` Greg Kurz
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=20210914103406.7d38f446@bahia.huguette \
--to=groug@kaod.org \
--cc=danielhb413@gmail.com \
--cc=david@gibson.dropbear.id.au \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/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).