From: Zhao Liu <zhao1.liu@intel.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "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>,
"Eric Blake" <eblake@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Marcelo Tosatti" <mtosatti@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
"Sia Jee Heng" <jeeheng.sia@starfivetech.com>,
"Alireza Sanaee" <alireza.sanaee@huawei.com>,
qemu-devel@nongnu.org, kvm@vger.kernel.org,
qemu-riscv@nongnu.org, qemu-arm@nongnu.org,
"Zhenyu Wang" <zhenyu.z.wang@intel.com>,
"Dapeng Mi" <dapeng1.mi@linux.intel.com>,
"Zhao Liu" <zhao1.liu@intel.com>
Subject: Re: [PATCH v3 6/7] i386/pc: Support cache topology in -machine for PC machine
Date: Fri, 18 Oct 2024 11:57:36 +0800 [thread overview]
Message-ID: <ZxHcsPyqT6MLJ9hG@intel.com> (raw)
In-Reply-To: <ZxEs3DGGgCqGT5yK@redhat.com>
Hi Daniel,
> > + ``smp-cache.0.cache=cachename,smp-cache.0.topology=topologylevel``
> > + Define cache properties for SMP system.
> > +
> > + ``cache=cachename`` specifies the cache that the properties will be
> > + applied on. This field is the combination of cache level and cache
> > + type. It supports ``l1d`` (L1 data cache), ``l1i`` (L1 instruction
> > + cache), ``l2`` (L2 unified cache) and ``l3`` (L3 unified cache).
> > +
> > + ``topology=topologylevel`` sets the cache topology level. It accepts
> > + CPU topology levels including ``thread``, ``core``, ``module``,
> > + ``cluster``, ``die``, ``socket``, ``book``, ``drawer`` and a special
> > + value ``default``. If ``default`` is set, then the cache topology will
> > + follow the architecture's default cache topology model. If another
> > + topology level is set, the cache will be shared at corresponding CPU
> > + topology level. For example, ``topology=core`` makes the cache shared
> > + by all threads within a core.
> > +
> > + Example:
> > +
> > + ::
> > +
> > + -machine smp-cache.0.cache=l1d,smp-cache.0.topology=core,smp-cache.1.cache=l1i,smp-cache.1.topology=core
>
> There are 4 cache types, l1d, l1i, l2, l3.
>
> In this example you've only set properties for l1d, l1i caches.
>
> What does this mean for l2 / l3 caches ?
Omitting "cache" will default to using the "default" level.
I think I should add the above description to the documentation.
> Are they reported as not existing, or are they to be reported at
> some built-in default topology level.
It's the latter.
If a machine doesn't support l2/l3, then QEMU will also report the error
like:
qemu-system-*: l2 cache topology not supported by this machine
> If the latter, how does the user know what that built-in default is,
Currently, the default cache model for x86 is L1 per core, L2 per core,
and L3 per die. Similar to the topology levels, there is still no way to
expose this to users. I can descript default cache model in doc.
But I feel like we're back to the situation we discussed earlier:
"default" CPU topology support should be related to the CPU model, but
in practice, QEMU supports it at the machine level. The cache topology
depends on CPU topology support and can only continue to be added on top
of the machine.
So do you think we can add topology and cache information in CpuModelInfo
so that query-cpu-model-expansion can expose default CPU/cache topology
information to users?
This way, users can customize CPU/cache topology in -smp and
-machine smp-cache. Although the QMP command is targeted at the CPU model
while our CLI is at the machine level, at least we can expose the
information to users.
If you agree to expose the default topology/cache info in
query-cpu-model-expansion, can I work on this in a separate series? :)
> and avoid nonsense like l1d being at socket level, and l3 being at the
> core level ?
Thank you! I ensured l1 must be lower than l2 and l2 must be lower than
l3, but missed l1 must be lower than l3.
The level check is incomplete due to the influence of "default." I think
the check should be placed after the arch CPU sets the cache model,
so that "default" is consumed.
> Can we explicitly disable a l2/l3 cache, or must it always exists ?
Now we can't disable it through -machine smp-cache (while x86 CPU support
l3-cache=off), but as you mentioned, I can try using "invalid" to support
this scenario, which would be more general. Similarly, if you agree, I
can also add this support in a separate series.
> The QAPI has an "invalid" topology level. You've not documented
> that as permitted here, but the qapi parser will happily allow
> it. What semantics will that have ?
Because the current this patch throws an error for "invalid", so I didn't
included it in the doc.
Thanks,
Zhao
next prev parent reply other threads:[~2024-10-18 3:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-12 10:44 [PATCH v3 0/7] Introduce SMP Cache Topology Zhao Liu
2024-10-12 10:44 ` [PATCH v3 1/7] hw/core: Make CPU topology enumeration arch-agnostic Zhao Liu
[not found] ` <20241017095227.00006d85@Huawei.com>
2024-10-17 13:20 ` Jonathan Cameron via
2024-10-17 14:51 ` Zhao Liu
2024-10-17 15:30 ` Daniel P. Berrangé
2024-10-18 2:36 ` Zhao Liu
2024-10-18 7:55 ` Daniel P. Berrangé
2024-10-18 9:01 ` Zhao Liu
2024-10-17 16:19 ` Marcin Juszkiewicz
2024-10-18 4:26 ` Zhao Liu
2024-10-12 10:44 ` [PATCH v3 2/7] qapi/qom: Define cache enumeration and properties for machine Zhao Liu
2024-10-12 10:44 ` [PATCH v3 3/7] hw/core: Check smp cache topology support " Zhao Liu
2024-10-12 10:44 ` [PATCH v3 4/7] i386/cpu: Support thread and module level cache topology Zhao Liu
2024-10-12 10:44 ` [PATCH v3 5/7] i386/cpu: Update cache topology with machine's configuration Zhao Liu
2024-10-12 10:44 ` [PATCH v3 6/7] i386/pc: Support cache topology in -machine for PC machine Zhao Liu
2024-10-17 15:27 ` Daniel P. Berrangé
2024-10-18 3:57 ` Zhao Liu [this message]
2024-10-18 7:58 ` Daniel P. Berrangé
2024-10-18 9:03 ` Zhao Liu
2024-10-12 10:44 ` [PATCH v3 7/7] i386/cpu: add has_caches flag to check smp_cache configuration Zhao Liu
2024-10-17 13:16 ` Jonathan Cameron via
2024-10-17 13:19 ` [PATCH v3 0/7] Introduce SMP Cache Topology Jonathan Cameron via
[not found] ` <20241017141402.0000135b@Huawei.com>
2024-10-17 15:01 ` 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=ZxHcsPyqT6MLJ9hG@intel.com \
--to=zhao1.liu@intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=alex.bennee@linaro.org \
--cc=alireza.sanaee@huawei.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dapeng1.mi@linux.intel.com \
--cc=eblake@redhat.com \
--cc=eduardo@habkost.net \
--cc=imammedo@redhat.com \
--cc=jeeheng.sia@starfivetech.com \
--cc=kvm@vger.kernel.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=wangyanan55@huawei.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).