From: Zhao Liu <zhao1.liu@intel.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: "Daniel P . Berrang�" <berrange@redhat.com>,
"Igor Mammedov" <imammedo@redhat.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Philippe Mathieu-Daud�" <philmd@linaro.org>,
"Yanan Wang" <wangyanan55@huawei.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Sergio Lopez" <slp@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Anthony PERARD" <anthony@xenproject.org>,
"Paul Durrant" <paul@xen.org>,
"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
"Eric Blake" <eblake@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Alex Benn�e" <alex.bennee@linaro.org>,
"Peter Maydell" <peter.maydell@linaro.org>,
qemu-devel@nongnu.org, kvm@vger.kernel.org, qemu-arm@nongnu.org,
"Zhenyu Wang" <zhenyu.z.wang@intel.com>,
"Dapeng Mi" <dapeng1.mi@linux.intel.com>,
"Yongwei Ma" <yongwei.ma@intel.com>,
"Zhao Liu" <zhao1.liu@intel.com>
Subject: Re: [RFC v2 00/12] Introduce Hybrid CPU Topology via Custom Topology Tree
Date: Wed, 9 Oct 2024 14:01:30 +0800 [thread overview]
Message-ID: <ZwYcOuZAt7qX5ci3@intel.com> (raw)
In-Reply-To: <20241008113038.00007ee4@Huawei.com>
Hi Jonathan,
Thank you for looking at here!
On Tue, Oct 08, 2024 at 11:30:38AM +0100, Jonathan Cameron wrote:
> Date: Tue, 8 Oct 2024 11:30:38 +0100
> From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
> Subject: Re: [RFC v2 00/12] Introduce Hybrid CPU Topology via Custom
> Topology Tree
> X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32)
>
> On Thu, 19 Sep 2024 14:11:16 +0800
> Zhao Liu <zhao1.liu@intel.com> wrote:
>
>
> > -smp maxsockets=1,maxdies=1,maxmodules=2,maxcores=2,maxthreads=2
> > -machine pc,custom-topo=on \
> > -device cpu-socket,id=sock0 \
> > -device cpu-die,id=die0,bus=sock0 \
> > -device cpu-module,id=mod0,bus=die0 \
> > -device cpu-module,id=mod1,bus=die0 \
> > -device x86-intel-core,id=core0,bus=mod0 \
> > -device x86-intel-atom,id=core1,bus=mod1 \
> > -device x86-intel-atom,id=core2,bus=mod1 \
> > -device host-x86_64-cpu,id=cpu0,socket-id=0,die-id=0,module-id=0,core-id=0,thread-id=0 \
> > -device host-x86_64-cpu,id=cpu1,socket-id=0,die-id=0,module-id=0,core-id=0,thread-id=1 \
> > -device host-x86_64-cpu,id=cpu2,socket-id=0,die-id=0,module-id=1,core-id=0,thread-id=0 \
> > -device host-x86_64-cpu,id=cpu3,socket-id=0,die-id=0,module-id=1,core-id=1,thread-id=0
>
> I quite like this as a way of doing the configuration but that needs
> some review from others.
Thanks!
> Peter, Alex, do you think this scheme is flexible enough to ultimately
> allow us to support this for arm?
I was also hoping that being generic enough would benefit ARM.
> >
> > This does not accommodate hybrid topologies. Therefore, we introduce
> > max* parameters: maxthreads/maxcores/maxmodules/maxdies/maxsockets
> > (for x86), to predefine the topology framework for the machine. These
> > parameters also constrain subsequent custom topologies, ensuring the
> > number of child devices under each parent device does not exceed the
> > specified max limits.
>
> To my thinking this seems like a good solution even though it's a
> bunch more smp parameters.
>
> What does this actually mean for hotplug of CPUs? What cases work
> with this setup?
My solution for this does not change the current CPU hotplug, because the
current cpu hotplug only needs to consider smp.cpus and smp.maxcpus.
But when a cpu is plugged in, machine needs to make sure that plugging
into the core doesn't break the maxthreads limit. Similarly, if one wants
to support hotplugging at the socket/die/core granularity, he will need
to make sure that the new topology meets the limits set by the max
parameters, which are the equivalent of preemptively leaving some empty
holes that can be utilized by hotplug.
> > Therefore, once user wants to customize topology by "-machine
> > custom-topo=on", the machine, that supports custom topology, will skip
> > the default topology creation as well as the default CPU creation.
>
> Seems sensible to me.
Thank you! Glad to have your support.
Regards,
Zhao
next prev parent reply other threads:[~2024-10-09 5:47 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-19 6:11 [RFC v2 00/12] Introduce Hybrid CPU Topology via Custom Topology Tree Zhao Liu
2024-09-19 6:11 ` [RFC v2 01/12] qdev: Allow qdev_device_add() to add specific category device Zhao Liu
2024-10-08 9:14 ` Jonathan Cameron via
2024-10-09 6:09 ` Zhao Liu
2024-09-19 6:11 ` [RFC v2 02/12] qdev: Introduce new device category to cover basic topology device Zhao Liu
2024-09-19 6:11 ` [RFC v2 03/12] system/vl: Create CPU topology devices from CLI early Zhao Liu
2024-10-08 9:50 ` Jonathan Cameron via
2024-10-09 6:31 ` Zhao Liu
2024-10-08 9:55 ` Jonathan Cameron via
2024-10-09 6:11 ` Zhao Liu
2024-09-19 6:11 ` [RFC v2 04/12] hw/core/machine: Split machine initialization around qemu_add_cli_devices_early() Zhao Liu
2024-09-19 6:11 ` [RFC v2 05/12] hw/core/machine: Introduce custom CPU topology with max limitations Zhao Liu
2024-10-08 10:16 ` Jonathan Cameron via
2024-09-19 6:11 ` [RFC v2 06/12] hw/cpu: Constrain CPU topology tree with max_limit Zhao Liu
2024-09-19 6:11 ` [RFC v2 07/12] hw/core: Re-implement topology helpers to honor max limitations Zhao Liu
2024-09-19 6:11 ` [RFC v2 08/12] hw/i386: Use get_max_topo_by_level() to get topology information Zhao Liu
2024-09-19 6:11 ` [RFC v2 09/12] i386: Introduce x86 CPU core abstractions Zhao Liu
2024-09-19 6:11 ` [RFC v2 10/12] i386/cpu: Support Intel hybrid CPUID Zhao Liu
2024-09-19 6:11 ` [RFC v2 11/12] i386/machine: Split machine initialization after CPU creation into post_init() Zhao Liu
2024-09-19 6:11 ` [RFC v2 12/12] i386: Support custom topology for microvm, pc-i440fx and pc-q35 Zhao Liu
2024-10-08 10:30 ` [RFC v2 00/12] Introduce Hybrid CPU Topology via Custom Topology Tree Jonathan Cameron via
2024-10-09 6:01 ` Zhao Liu [this message]
2024-10-09 6:51 ` Zhao Liu
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=ZwYcOuZAt7qX5ci3@intel.com \
--to=zhao1.liu@intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=alex.bennee@linaro.org \
--cc=anthony@xenproject.org \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dapeng1.mi@linux.intel.com \
--cc=eblake@redhat.com \
--cc=edgar.iglesias@gmail.com \
--cc=eduardo@habkost.net \
--cc=imammedo@redhat.com \
--cc=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=paul@xen.org \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=slp@redhat.com \
--cc=sstabellini@kernel.org \
--cc=wangyanan55@huawei.com \
--cc=yongwei.ma@intel.com \
--cc=zhenyu.z.wang@intel.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).