[RFC PATCH 0/3] Improve scalability of the SMP related Docs

[RFC PATCH 0/3] Improve scalability of the SMP related Docs

[Yanan Wang]

Hi,

The motivation of this series is to improve the scalability of SMP
related Docs, so that we can easily/clearly extend them without making
confusion when we plan to introduce more target specific CPU topology
members (e.g. CPU cluster in Arm and CPU drawer/book in s390).

With more and more target specific CPU topology members introduced,
it may not be a good method any longer to put all the mixed parameters
into one single hierarchy and then describe the exact meaning of each
member in the Docs, which makes confusion for the reader. On the contrary,
it may be clearer to describe the currently supported sub-hierarchies
separately and better to list some examples in the Docs. For example,
for now we can describe "sockets/cores/threads" and "sockets/dies/cores/
threads" separately from the mixture of "sockets | dies | cores | threads",
and more sub-hierarchies can be described when new parameters are added.

Based on above consideration, correspondingly -smp docs in qemu-options,
comment of struct CpuTopology and SMP related comments in qapi/machine
are somehow rewritten.

Besides the maintainers, I also keep some people on Cc list who may be
interested in having a look at this. Comments welcome!

Thanks,
Yanan
.

Yanan Wang (3):
  qemu-options: Improve scalability of the -smp documentation
  include/hw/boards: Improve scalability of the CpuTopology comment
  qapi/machine.json: Improve scalability of the SMP related comments

 include/hw/boards.h | 26 +++++++++++--
 qapi/machine.json   | 47 ++++++++++++++++++-----
 qemu-options.hx     | 90 ++++++++++++++++++++++++++++++++++++---------
 3 files changed, 133 insertions(+), 30 deletions(-)

--
2.19.1

[RFC PATCH 1/3] qemu-options: Improve scalability of the -smp documentation

[Yanan Wang]

Rewrite part of the -smp documentation in qemu-option.hx,
so that we can easily/clearly extend it with more target
specific CPU topology members introduced in the future.

Signed-off-by: Yanan Wang <wangyanan55@huawei.com>
---
 qemu-options.hx | 90 +++++++++++++++++++++++++++++++++++++++----------
 1 file changed, 73 insertions(+), 17 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 5f375bbfa6..212657d689 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -207,14 +207,29 @@ ERST
 
 DEF("smp", HAS_ARG, QEMU_OPTION_smp,
     "-smp [[cpus=]n][,maxcpus=maxcpus][,sockets=sockets][,dies=dies][,cores=cores][,threads=threads]\n"
-    "                set the number of CPUs to 'n' [default=1]\n"
+    "                set the number of initial CPUs to 'n' [default=1]\n"
     "                maxcpus= maximum number of total CPUs, including\n"
     "                offline CPUs for hotplug, etc\n"
-    "                sockets= number of discrete sockets in the system\n"
-    "                dies= number of CPU dies on one socket (for PC only)\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",
-        QEMU_ARCH_ALL)
+    "                sockets= number of sockets per upper layer container\n"
+    "                dies= number of dies per upper layer container\n"
+    "                cores= number of cores per upper layer container\n"
+    "                threads= number of threads per upper layer container\n"
+    "Note: Different machines may have different subsets of the CPU topology\n"
+    "      parameters supported, so the description of the supported parameters\n"
+    "      will vary accordingly. For example, for a machine that supports a\n"
+    "      CPU hierarchy of sockets/cores/threads, the parameters will sequentially\n"
+    "      mean as below:\n"
+    "                sockets= the total number of sockets on the machine board\n"
+    "                which is the upper layer container of socket\n"
+    "                cores= the number of cores per socket\n"
+    "                which is the upper layer container of core\n"
+    "                threads= the number of threads per core\n"
+    "                which is the upper layer container of thread\n"
+    "      For a particular machine type board, an expected CPU topology hierarchy\n"
+    "      can be defined through the supported sub-option. Unsupported parameters\n"
+    "      can also be provided in addition to the sub-option, but their values\n"
+    "      must be set as 1 in the purpose of correct parsing.\n",
+    QEMU_ARCH_ALL)
 SRST
 ``-smp [[cpus=]n][,maxcpus=maxcpus][,sockets=sockets][,dies=dies][,cores=cores][,threads=threads]``
     Simulate a SMP system with '\ ``n``\ ' CPUs initially present on
@@ -225,27 +240,68 @@ SRST
     initial CPU count will match the maximum number. When only one of them
     is given then the omitted one will be set to its counterpart's value.
     Both parameters may be specified, but the maximum number of CPUs must
-    be equal to or greater than the initial CPU count. Both parameters are
-    subject to an upper limit that is determined by the specific machine
-    type chosen.
-
-    To control reporting of CPU topology information, the number of sockets,
-    dies per socket, cores per die, and threads per core can be specified.
-    The sum `` sockets * cores * dies * threads `` must be equal to the
-    maximum CPU count. CPU targets may only support a subset of the topology
-    parameters. Where a CPU target does not support use of a particular
-    topology parameter, its value should be assumed to be 1 for the purpose
-    of computing the CPU maximum count.
+    be equal to or greater than the initial CPU count. Product of the
+    CPU topology hierarchy must be equal to the maximum number of CPUs.
+    Both parameters are subject to an upper limit that is determined by
+    the specific machine type chosen.
+
+    To control reporting of CPU topology information, values of the topology
+    parameters can be specified. Machines may only support a subset of the
+    parameters and different machines may have different subsets supported
+    which vary depending on capacity of the corresponding CPU targets. So
+    for a particular machine type board, an expected topology hierarchy can
+    be defined through the supported sub-option. Unsupported parameters can
+    also be provided in addition to the sub-option, but their values must be
+    set as 1 in the purpose of correct parsing.
 
     Either the initial CPU count, or at least one of the topology parameters
     must be specified. The specified parameters must be greater than zero,
     explicit configuration like "cpus=0" is not allowed. Values for any
     omitted parameters will be computed from those which are given.
+
+    For example, the following sub-option defines a CPU topology hierarchy
+    (2 sockets totally on the machine, 2 cores per socket, 2 threads per
+    core) for a machine that only supports sockets/cores/threads.
+    Some members of the option can be omitted but their values will be
+    automatically computed:
+
+    ::
+
+        -smp 8,sockets=2,cores=2,threads=2,maxcpus=8
+
+    The following sub-option defines a CPU topology hierarchy (2 sockets
+    totally on the machine, 2 dies per socket, 2 cores per die, 2 threads
+    per core) for the PC machine which supports sockets/dies/cores/threads.
+    Some members of the option can be omitted but their values will be
+    automatically computed:
+
+    ::
+
+        -smp 16,sockets=2,dies=2,cores=2,threads=2,maxcpus=16
+
+    The following option provides all the CPU topology parameters for a
+    machine that only support sockets/cores/threads, but values of the
+    unsupported parameters are set as 1. The defined hierarchy for the
+    machine will be 2 sockets totally, 2 cores per socket, 2 threads per
+    core. Some members of the option can be omitted but their values will
+    be automatically computed:
+
+    ::
+
+        -smp 8,sockets=2,dies=1,cores=2,threads=2,maxcpus=8
+
     Historically preference was given to the coarsest topology parameters
     when computing missing values (ie sockets preferred over cores, which
     were preferred over threads), however, this behaviour is considered
     liable to change. Prior to 6.2 the preference was sockets over cores
     over threads. Since 6.2 the preference is cores over sockets over threads.
+
+    For example, the following option defines a machine board with 2 sockets
+    of 1 core before 6.2 and 1 socket of 2 cores after 6.2:
+
+    ::
+
+        -smp 2
 ERST
 
 DEF("numa", HAS_ARG, QEMU_OPTION_numa,
-- 
2.19.1

[RFC PATCH 2/3] include/hw/boards: Improve scalability of the CpuTopology comment

[Yanan Wang]

Rewrite the comment of struct CpuTopology in include/hw/boards.h,
so that we can easily/clearly extend it with more target specific
CPU topology members introduced in the future.

Signed-off-by: Yanan Wang <wangyanan55@huawei.com>
---
 include/hw/boards.h | 26 ++++++++++++++++++++++----
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/include/hw/boards.h b/include/hw/boards.h
index 5adbcbb99b..19c5419174 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -280,11 +280,29 @@ typedef struct DeviceMemoryState {
 /**
  * CpuTopology:
  * @cpus: the number of present logical processors on the machine
- * @sockets: the number of sockets on the machine
- * @dies: the number of dies in one socket
- * @cores: the number of cores in one die
- * @threads: the number of threads in one core
+ * @sockets: the number of sockets per upper layer container
+ * @dies: the number of dies per upper layer container
+ * @cores: the number of cores per upper layer container
+ * @threads: the number of threads per upper layer container
  * @max_cpus: the maximum number of logical processors on the machine
+ *
+ * Different machines may have different subsets of the CPU topology
+ * parameters supported, so the description of the supported parameters
+ * will vary accordingly. For example, for a machine that supports a
+ * CPU hierarchy of sockets/cores/threads, the members will sequentially
+ * mean as below:
+ *    -sockets: the total number of sockets on the machine
+ *     which is the upper layer container of socket
+ *    -cores: the number of cores per socket
+ *     which is the upper layer container of core
+ *    -threads: the number of threads per core
+ *     which is the upper layer container of thread
+ *
+ * The currently supported CPU topology subsets are listed here:
+ * For PC machines, a 4-level CPU hierarchy is supported:
+ *    -sockets/dies/cores/threads
+ * For the other machines, a 3-level CPU hierarchy is supported:
+ *    -sockets/cores/threads
  */
 typedef struct CpuTopology {
     unsigned int cpus;
-- 
2.19.1

[RFC PATCH 3/3] qapi/machine.json: Improve scalability of the SMP related comments

[Yanan Wang]

Rewrite the comments related to SMP in qapi/machine.json,
so that we can easily/clearly extend it with more target
specific CPU topology members introduced in the future.

Signed-off-by: Yanan Wang <wangyanan55@huawei.com>
---
 qapi/machine.json | 47 ++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 38 insertions(+), 9 deletions(-)

diff --git a/qapi/machine.json b/qapi/machine.json
index 5db54df298..2eda8e996e 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -866,10 +866,15 @@
 # a CPU is being hotplugged.
 #
 # @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 node/board the CPU belongs to (Since 4.1)
-# @core-id: core number within die the CPU belongs to
-# @thread-id: thread number within core the CPU belongs to
+#
+# @socket-id: socket number within the upper layer container the CPU belongs to
+#
+# @die-id: die number within the upper layer container the CPU belongs to
+#          (since 4.1)
+#
+# @core-id: core number within the upper layer container the CPU belongs to
+#
+# @thread-id: thread number within the upper layer container the CPU belongs to
 #
 # Note: currently there are 5 properties that could be present
 #       but management should be prepared to pass through other
@@ -877,6 +882,15 @@
 #       interface extension. This also requires the filed names to be kept in
 #       sync with the properties passed to -device/device_add.
 #
+#       Different machines may have different subsets of the CPU topology
+#       parameters supported, so the description of the supported parameters
+#       in this struct will vary accordingly. For example, for a machine that
+#       supports a CPU hierarchy of sockets/cores/threads, the description of
+#       the supported members will be: @socket-id means socket number within
+#       node/board the CPU belongs to, @core-id means core number within socket
+#       the CPU belongs to, @thread-id means thread number within core the CPU
+#       belongs to.
+#
 # Since: 2.7
 ##
 { 'struct': 'CpuInstanceProperties',
@@ -1390,19 +1404,34 @@
 # Schema for CPU topology configuration.  A missing value lets
 # QEMU figure out a suitable value based on the ones that are provided.
 #
-# @cpus: number of virtual CPUs in the virtual machine
+# @cpus: number of present virtual CPUs in the virtual machine
 #
-# @sockets: number of sockets in the CPU topology
+# @sockets: number of sockets per upper layer container in the CPU topology
 #
-# @dies: number of dies per socket in the CPU topology
+# @dies: number of dies per upper layer container in the CPU topology
+#        (since 4.1)
 #
-# @cores: number of cores per die in the CPU topology
+# @cores: number of cores per upper layer container in the CPU topology
 #
-# @threads: number of threads per core in the CPU topology
+# @threads: number of threads per upper layer container in the CPU topology
 #
 # @maxcpus: maximum number of hotpluggable virtual CPUs in the virtual machine
 #
+# Notes: Different machines may have different subsets of the CPU topology
+#        parameters supported, so the description of the supported parameters
+#        in this struct will vary accordingly. For example, for a machine
+#        that supports a CPU hierarchy of sockets/cores/threads, the
+#        description of the supported members will be: @sockets means the
+#        total number of sockets on the machine which is the upper layer
+#        container of socket, @cores means the number of cores per socket
+#        which is the upper layer container of core, @threads means the number
+#        of threads per core which is the upper layer container of thread.
+#
+#        Unsupported parameters can also be provided in this struct, but their
+#        values must be set as 1 in the purpose of correct parsing.
+#
 # Since: 6.1
+#
 ##
 { 'struct': 'SMPConfiguration', 'data': {
      '*cpus': 'int',
-- 
2.19.1

Re: [RFC PATCH 0/3] Improve scalability of the SMP related Docs

[wangyanan (Y)]

Ping...

Is this a right direction to go or should I continue on with this ?

On 2021/10/7 18:43, Yanan Wang wrote:
> Hi,
>
> The motivation of this series is to improve the scalability of SMP
> related Docs, so that we can easily/clearly extend them without making
> confusion when we plan to introduce more target specific CPU topology
> members (e.g. CPU cluster in Arm and CPU drawer/book in s390).
>
> With more and more target specific CPU topology members introduced,
> it may not be a good method any longer to put all the mixed parameters
> into one single hierarchy and then describe the exact meaning of each
> member in the Docs, which makes confusion for the reader. On the contrary,
> it may be clearer to describe the currently supported sub-hierarchies
> separately and better to list some examples in the Docs. For example,
> for now we can describe "sockets/cores/threads" and "sockets/dies/cores/
> threads" separately from the mixture of "sockets | dies | cores | threads",
> and more sub-hierarchies can be described when new parameters are added.
>
> Based on above consideration, correspondingly -smp docs in qemu-options,
> comment of struct CpuTopology and SMP related comments in qapi/machine
> are somehow rewritten.
>
> Besides the maintainers, I also keep some people on Cc list who may be
> interested in having a look at this. Comments welcome!
>
> Thanks,
> Yanan
> .
>
> Yanan Wang (3):
>    qemu-options: Improve scalability of the -smp documentation
>    include/hw/boards: Improve scalability of the CpuTopology comment
>    qapi/machine.json: Improve scalability of the SMP related comments
>
>   include/hw/boards.h | 26 +++++++++++--
>   qapi/machine.json   | 47 ++++++++++++++++++-----
>   qemu-options.hx     | 90 ++++++++++++++++++++++++++++++++++++---------
>   3 files changed, 133 insertions(+), 30 deletions(-)
>
> --
> 2.19.1
>
> .