qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Yanan Wang <wangyanan55@huawei.com>
To: Peter Maydell <peter.maydell@linaro.org>,
	Andrew Jones <drjones@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Shannon Zhao <shannon.zhaosl@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	David Gibson <david@gibson.dropbear.id.au>,
	<qemu-devel@nongnu.org>, <qemu-arm@nongnu.org>
Cc: Barry Song <song.bao.hua@hisilicon.com>,
	Yanan Wang <wangyanan55@huawei.com>,
	prime.zeng@hisilicon.com, wanghaibin.wang@huawei.com,
	yuzenghui@huawei.com, yangyicong@huawei.com,
	zhukeqian1@huawei.com
Subject: [RFC PATCH v4 1/7] vl: Add expose=on|off option support in -smp command line
Date: Tue, 22 Jun 2021 17:34:07 +0800	[thread overview]
Message-ID: <20210622093413.13360-2-wangyanan55@huawei.com> (raw)
In-Reply-To: <20210622093413.13360-1-wangyanan55@huawei.com>

Once the view of virtual cpu topology is provided to guest kernel,
with a well-designed vCPU pinning to the pCPU we could get a huge
benefit, e.g., the scheduling performance improvement. However a
virtual cpu topology view of guest may also have a negative impact
if the pinning is badly-designed. See Dario Faggioli's research
and the related performance tests in [1] for reference.

[1] https://kvmforum2020.sched.com/event/eE1y/virtual-topology-
for-virtual-machines-friend-or-foe-dario-faggioli-suse

So here we go, let's introduce support of generating cpu topology
descriptions to the guest. However, instead of quietly enforcing
the support for the latest machine type, we'd better introduce a
new parameter "expose=on|off" in -smp command line to leave QEMU
users a choice to decide whether to enable the feature or not.
This will allow the feature to work on different machine types
and also ideally compat with already in-use -smp command lines.

Furthermore, based on existing parsing rules of -smp command line
in generic smp_parse() which allows to compute the missing values,
another more strict rule is introduced to follow when exposure of
cpu topology is enabled. With "expose=on", it's important to know
what users actually want, so we require that all of cpus/sockets/
cores/threads must be provided while maxcpus is optional.
Hopefully the new rule will apply to all kinds of architectures
which support the feature.

In conclusion, if a QEMU user doesn't hope to enable the virtual
cpu topology support, then feel free to configure a -smp cmdline
like below and everything will work just like before:
-smp 96
-smp 96,expose=off
-smp 96,sockets=2
-smp 96,sockets=2,expose=off
...

While if a QEMU user is ready to take advantage of the virtual cpu
topology support, then he must configure an accurate -smp cmdline
like below, on different machine types:
-smp 96,sockets=2,cores=48,threads=1,expose=on
-smp 96,maxcpus=96,sockets=2,cores=48,threads=1,expose=on

Suggested-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Yanan Wang <wangyanan55@huawei.com>
---
 qemu-options.hx | 24 +++++++++++++++---------
 softmmu/vl.c    |  3 +++
 2 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 14258784b3..d18d64958b 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -196,25 +196,31 @@ SRST
 ERST
 
 DEF("smp", HAS_ARG, QEMU_OPTION_smp,
-    "-smp [cpus=]n[,maxcpus=cpus][,cores=cores][,threads=threads][,dies=dies][,sockets=sockets]\n"
+    "-smp [cpus=]n[,maxcpus=cpus][,cores=cores][,threads=threads][,dies=dies][,sockets=sockets][,expose=on|off]\n"
     "                set the number of CPUs to 'n' [default=1]\n"
     "                maxcpus= maximum number of total cpus, including\n"
     "                offline CPUs for hotplug, etc\n"
     "                cores= number of CPU cores on one socket (for PC, it's on one die)\n"
     "                threads= number of threads on one CPU core\n"
     "                dies= number of CPU dies on one socket (for PC only)\n"
-    "                sockets= number of discrete sockets in the system\n",
+    "                sockets= number of discrete sockets in the system\n"
+    "                expose=on|off controls support for exposing cpu topology\n"
+    "                to the guest (default=off)\n",
         QEMU_ARCH_ALL)
 SRST
-``-smp [cpus=]n[,cores=cores][,threads=threads][,dies=dies][,sockets=sockets][,maxcpus=maxcpus]``
+``-smp [cpus=]n[,cores=cores][,threads=threads][,dies=dies][,sockets=sockets][,maxcpus=maxcpus][,expose=on|off]``
     Simulate an SMP system with n CPUs. On the PC target, up to 255 CPUs
-    are supported. On Sparc32 target, Linux limits the number of usable
-    CPUs to 4. For the PC target, the number of cores per die, the
-    number of threads per cores, the number of dies per packages and the
-    total number of sockets can be specified. Missing values will be
-    computed. If any on the three values is given, the total number of
-    CPUs n can be omitted. maxcpus specifies the maximum number of
+    are supported. On the Sparc32 target, Linux limits the number of usable
+    CPUs to 4. For the PC target, the number of cores per die, the number
+    of threads per core, the number of dies per package and the total number
+    of sockets can be specified. maxcpus specifies the maximum number of
     hotpluggable CPUs.
+
+    With "expose=off" or not explicitly specified, missing values will be
+    computed, and the total number of CPUs n can be omitted if any on the
+    three values is given. Otherwise with "expose=on", much more detailed
+    configuration is required: cpus/sockets/cores/threads must be given,
+    while maxcpus is optional.
 ERST
 
 DEF("numa", HAS_ARG, QEMU_OPTION_numa,
diff --git a/softmmu/vl.c b/softmmu/vl.c
index feb4d201f3..f4b59571c7 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -729,6 +729,9 @@ static QemuOptsList qemu_smp_opts = {
         }, {
             .name = "maxcpus",
             .type = QEMU_OPT_NUMBER,
+        }, {
+            .name = "expose",
+            .type = QEMU_OPT_BOOL,
         },
         { /*End of list */ }
     },
-- 
2.23.0



  reply	other threads:[~2021-06-22  9:39 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-22  9:34 [RFC PATCH v4 0/7] hw/arm/virt: Introduce cpu topology support Yanan Wang
2021-06-22  9:34 ` Yanan Wang [this message]
2021-06-22  9:34 ` [RFC PATCH v4 2/7] hw/arm/virt: Add separate -smp parsing function for ARM machines Yanan Wang
2021-06-22  9:34 ` [RFC PATCH v4 3/7] machine: disallow -smp expose=on for non-ARM machines Yanan Wang
2021-06-22  9:34 ` [RFC PATCH v4 4/7] device_tree: Add qemu_fdt_add_path Yanan Wang
2021-06-22  9:34 ` [RFC PATCH v4 5/7] hw/arm/virt: Add cpu-map to device tree Yanan Wang
2021-06-22  9:34 ` [RFC PATCH v4 6/7] hw/acpi/aml-build: Add Processor hierarchy node structure Yanan Wang
2021-06-22  9:34 ` [RFC PATCH v4 7/7] hw/acpi/aml-build: Generate PPTT table Yanan Wang
2021-06-22 10:18 ` [RFC PATCH v4 0/7] hw/arm/virt: Introduce cpu topology support Daniel P. Berrangé
2021-06-22 11:46   ` Andrew Jones
2021-06-22 12:31     ` wangyanan (Y)
2021-06-22 12:41       ` Daniel P. Berrangé
2021-06-22 14:04         ` wangyanan (Y)
2021-06-22 14:10           ` Daniel P. Berrangé
2021-06-22 14:15             ` Peter Maydell
2021-06-22 14:28               ` Daniel P. Berrangé
2021-06-28 11:14                 ` wangyanan (Y)
2021-06-28 11:31                   ` Daniel P. Berrangé
2021-06-28 11:53                     ` wangyanan (Y)
2021-06-22 14:29             ` Andrew Jones
2021-06-22 15:15               ` Daniel P. Berrangé
2021-06-22 15:40               ` Igor Mammedov
2021-06-22 17:08                 ` Andrew Jones
2021-06-22 17:14                 ` Daniel P. Berrangé
2021-06-22 17:29                   ` Andrew Jones
2021-06-22 17:39                     ` Daniel P. Berrangé
2021-06-28  8:43                       ` wangyanan (Y)
2021-06-28  8:58                         ` Andrew Jones
2021-06-28 10:48                           ` wangyanan (Y)
2021-06-30  6:36                           ` wangyanan (Y)
2021-06-30  8:30                             ` Andrew Jones
2021-06-30  9:37                               ` wangyanan (Y)
2021-06-30 11:56                                 ` Andrew Jones
2021-07-01  6:15                                   ` wangyanan (Y)

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=20210622093413.13360-2-wangyanan55@huawei.com \
    --to=wangyanan55@huawei.com \
    --cc=alistair.francis@wdc.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=drjones@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=prime.zeng@hisilicon.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shannon.zhaosl@gmail.com \
    --cc=song.bao.hua@hisilicon.com \
    --cc=wanghaibin.wang@huawei.com \
    --cc=yangyicong@huawei.com \
    --cc=yuzenghui@huawei.com \
    --cc=zhukeqian1@huawei.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).