All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "wangyanan (Y)" <wangyanan55@huawei.com>
Cc: peter.maydell@linaro.org, drjones@redhat.com,
	Gavin Shan <gshan@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	richard.henderson@linaro.org, qemu-devel@nongnu.org,
	zhenyzha@redhat.com, qemu-arm@nongnu.org, shan.gavin@gmail.com,
	imammedo@redhat.com
Subject: Re: [PATCH v5 1/4] qapi/machine.json: Add cluster-id
Date: Tue, 19 Apr 2022 16:59:34 +0100	[thread overview]
Message-ID: <Yl7cZuRxBLX9qPlw@redhat.com> (raw)
In-Reply-To: <f45a3f17-7cef-3d8c-e79c-e6a5898e665e@huawei.com>

On Thu, Apr 14, 2022 at 10:27:25AM +0800, wangyanan (Y) wrote:
> Hi Gavin,
> 
> Cc: Daniel and Markus
> On 2022/4/14 8:06, Gavin Shan wrote:
> > Hi Yanan,
> > 
> > On 4/13/22 7:49 PM, wangyanan (Y) wrote:
> > > On 2022/4/3 22:59, Gavin Shan wrote:
> > > > This adds cluster-id in CPU instance properties, which will be used
> > > > by arm/virt machine. Besides, the cluster-id is also verified or
> > > > dumped in various spots:
> > > > 
> > > >    * hw/core/machine.c::machine_set_cpu_numa_node() to associate
> > > >      CPU with its NUMA node.
> > > > 
> > > >    * hw/core/machine.c::machine_numa_finish_cpu_init() to associate
> > > >      CPU with NUMA node when no default association isn't provided.
> > > > 
> > > >    * hw/core/machine-hmp-cmds.c::hmp_hotpluggable_cpus() to dump
> > > >      cluster-id.
> > > > 
> > > > Signed-off-by: Gavin Shan <gshan@redhat.com>
> > > > ---
> > > >   hw/core/machine-hmp-cmds.c |  4 ++++
> > > >   hw/core/machine.c          | 16 ++++++++++++++++
> > > >   qapi/machine.json          |  6 ++++--
> > > >   3 files changed, 24 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/hw/core/machine-hmp-cmds.c b/hw/core/machine-hmp-cmds.c
> > > > index 4e2f319aeb..5cb5eecbfc 100644
> > > > --- a/hw/core/machine-hmp-cmds.c
> > > > +++ b/hw/core/machine-hmp-cmds.c
> > > > @@ -77,6 +77,10 @@ void hmp_hotpluggable_cpus(Monitor *mon,
> > > > const QDict *qdict)
> > > >           if (c->has_die_id) {
> > > >               monitor_printf(mon, "    die-id: \"%" PRIu64
> > > > "\"\n", c->die_id);
> > > >           }
> > > > +        if (c->has_cluster_id) {
> > > > +            monitor_printf(mon, "    cluster-id: \"%" PRIu64 "\"\n",
> > > > +                           c->cluster_id);
> > > > +        }
> > > >           if (c->has_core_id) {
> > > >               monitor_printf(mon, "    core-id: \"%" PRIu64
> > > > "\"\n", c->core_id);
> > > >           }
> > > > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > > > index d856485cb4..8748b64657 100644
> > > > --- a/hw/core/machine.c
> > > > +++ b/hw/core/machine.c
> > > > @@ -677,6 +677,11 @@ void machine_set_cpu_numa_node(MachineState
> > > > *machine,
> > > >               return;
> > > >           }
> > > > +        if (props->has_cluster_id && !slot->props.has_cluster_id) {
> > > > +            error_setg(errp, "cluster-id is not supported");
> > > > +            return;
> > > > +        }
> > > > +
> > > >           if (props->has_socket_id && !slot->props.has_socket_id) {
> > > >               error_setg(errp, "socket-id is not supported");
> > > >               return;
> > > > @@ -696,6 +701,11 @@ void machine_set_cpu_numa_node(MachineState
> > > > *machine,
> > > >                   continue;
> > > >           }
> > > > +        if (props->has_cluster_id &&
> > > > +            props->cluster_id != slot->props.cluster_id) {
> > > > +                continue;
> > > > +        }
> > > > +
> > > >           if (props->has_die_id && props->die_id !=
> > > > slot->props.die_id) {
> > > >                   continue;
> > > >           }
> > > > @@ -990,6 +1000,12 @@ static char *cpu_slot_to_string(const
> > > > CPUArchId *cpu)
> > > >           }
> > > >           g_string_append_printf(s, "die-id: %"PRId64,
> > > > cpu->props.die_id);
> > > >       }
> > > > +    if (cpu->props.has_cluster_id) {
> > > > +        if (s->len) {
> > > > +            g_string_append_printf(s, ", ");
> > > > +        }
> > > > +        g_string_append_printf(s, "cluster-id: %"PRId64,
> > > > cpu->props.cluster_id);
> > > > +    }
> > > >       if (cpu->props.has_core_id) {
> > > >           if (s->len) {
> > > >               g_string_append_printf(s, ", ");
> > > > diff --git a/qapi/machine.json b/qapi/machine.json
> > > > index 9c460ec450..ea22b574b0 100644
> > > > --- a/qapi/machine.json
> > > > +++ b/qapi/machine.json
> > > > @@ -868,10 +868,11 @@
> > > >   # @node-id: NUMA node ID the CPU belongs to
> > > >   # @socket-id: socket number within node/board the CPU belongs to
> > > >   # @die-id: die number within socket the CPU belongs to (since 4.1)
> > > > -# @core-id: core number within die the CPU belongs to
> > > > +# @cluster-id: cluster number within die the CPU belongs to
> We also need a "(since 7.1)" tag for cluster-id.
> > > I remember this should be "cluster number within socket..."
> > > according to Igor's comments in v3 ?
> > 
> > Igor had suggestion to correct the description for 'core-id' like
> > below, but he didn't suggest anything for 'cluster-id'. The question
> > is clusters are sub-components of die, instead of socket, if die
> > is supported? You may want to me change it like below and please
> > confirm.
> > 
> >   @cluster-id: cluster number within die/socket the CPU belongs to
> > 
> > suggestion from Ignor in v3:
> > 
> >    > +# @core-id: core number within cluster the CPU belongs to
> > 
> >    s:cluster:cluster/die:
> > 
> We want "within cluster/die" description for core-id because we
> support both "cores in cluster" for ARM and "cores in die" for X86.
> Base on this routine, we only need "within socket" for cluster-id
> because we currently only support "clusters in socket". Does this
> make sense?
> 
> Alternatively, the plainest documentation for the IDs is to simply
> range **-id only to its next level topo like below. This may avoid
> increasing complexity when more topo-ids are inserted middle.
> But whether this way is acceptable is up to the Maintainers. :)

Rather saying we only support cluster on ARM and only dies on x86,
I tend to view it as, we only support greater than 1 cluster on
ARM, and greater than 1 die on x86.

IOW, x86 implicitly always has exactly 1-and-only-1 cluster,
and arm implicitly always has exactly 1-and-only-1 die.

With this POV, then we can keep the description simple, only
refering to the immediately above level in the hierarchy.

> 
> # @socket-id: socket number within node/board the CPU belongs to
> # @die-id: die number within socket the CPU belongs to (since 4.1)
> # @cluster-id: cluster number within die the CPU belongs to (since 7.1)
> # @core-id: core number within cluster the CPU belongs to
> # @thread-id: thread number within core the CPU belongs to

So this suggested text is fine with me.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


  parent reply	other threads:[~2022-04-19 15:59 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-03 14:59 [PATCH v5 0/4] hw/arm/virt: Fix CPU's default NUMA node ID Gavin Shan
2022-04-03 14:59 ` [PATCH v5 1/4] qapi/machine.json: Add cluster-id Gavin Shan
2022-04-04  8:37   ` Daniel P. Berrangé
2022-04-04  8:40     ` Daniel P. Berrangé
2022-04-04 10:40       ` Gavin Shan
2022-04-13 11:49   ` wangyanan (Y) via
2022-04-13 11:49     ` wangyanan (Y) via
2022-04-14  0:06     ` Gavin Shan
2022-04-14  2:27       ` wangyanan (Y) via
2022-04-14  2:27         ` wangyanan (Y) via
2022-04-14  7:56         ` Gavin Shan
2022-04-14  9:33           ` wangyanan (Y) via
2022-04-19 15:59         ` Daniel P. Berrangé [this message]
2022-04-20  2:17           ` Gavin Shan
2022-04-03 14:59 ` [PATCH v5 2/4] hw/arm/virt: Consider SMP configuration in CPU topology Gavin Shan
2022-04-04  8:39   ` Daniel P. Berrangé
2022-04-04 10:48     ` Gavin Shan
2022-04-04 12:03       ` Igor Mammedov
2022-04-13 12:39   ` wangyanan (Y) via
2022-04-13 12:39     ` wangyanan (Y) via
2022-04-14  0:08     ` Gavin Shan
2022-04-14  2:27       ` wangyanan (Y) via
2022-04-14  2:27         ` wangyanan (Y) via
2022-04-14  2:37         ` Gavin Shan
2022-04-14  2:49           ` wangyanan (Y) via
2022-04-14  2:49             ` wangyanan (Y) via
2022-04-14  7:35             ` Gavin Shan
2022-04-14  9:29               ` wangyanan (Y) via
2022-04-14  9:29                 ` wangyanan (Y) via
2022-04-15  6:08                 ` Gavin Shan
2022-04-14  9:33               ` Jonathan Cameron via
2022-04-14  9:33                 ` Jonathan Cameron via
2022-04-15  6:13                 ` Gavin Shan
2022-04-03 14:59 ` [PATCH v5 3/4] hw/arm/virt: Fix CPU's default NUMA node ID Gavin Shan
2022-04-03 14:59 ` [PATCH v5 4/4] hw/acpi/aml-build: Use existing CPU topology to build PPTT table Gavin Shan
2022-04-12 15:40   ` Jonathan Cameron via
2022-04-12 15:40     ` Jonathan Cameron via
2022-04-13  2:15     ` Gavin Shan
2022-04-13 13:52   ` Igor Mammedov
2022-04-14  0:33     ` Gavin Shan
2022-04-14  2:56       ` wangyanan (Y) via
2022-04-14  2:56         ` wangyanan (Y) via
2022-04-14  7:39         ` Gavin Shan
2022-04-19  8:54       ` Igor Mammedov
2022-04-20  5:19         ` Gavin Shan
2022-04-20  8:10           ` Igor Mammedov
2022-04-20 10:22             ` Gavin Shan
2022-04-14  3:09   ` wangyanan (Y) via
2022-04-14  3:09     ` wangyanan (Y) via
2022-04-14  7:45     ` Gavin Shan
2022-04-14  9:22       ` wangyanan (Y) via
2022-04-14  9:22         ` wangyanan (Y) via
2022-04-11  6:48 ` [PATCH v5 0/4] hw/arm/virt: Fix CPU's default NUMA node ID 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=Yl7cZuRxBLX9qPlw@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=drjones@redhat.com \
    --cc=gshan@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=shan.gavin@gmail.com \
    --cc=wangyanan55@huawei.com \
    --cc=zhenyzha@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.