On Thu, Jan 02, 2025 at 06:01:41PM +0000, Alireza Sanaee wrote: > Date: Thu, 2 Jan 2025 18:01:41 +0000 > From: Alireza Sanaee <alireza.sanaee@xxxxxxxxxx> > Subject: Re: [PATCH v6 0/4] i386: Support SMP Cache Topology > X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) > > On Thu, 2 Jan 2025 11:09:51 -0600 > Rob Herring <robh@xxxxxxxxxx> wrote: > > > On Thu, Jan 2, 2025 at 8:57 AM Alireza Sanaee > > <alireza.sanaee@xxxxxxxxxx> wrote: > > > > > > On Wed, 25 Dec 2024 11:03:42 +0800 > > > Zhao Liu <zhao1.liu@xxxxxxxxx> wrote: > > > > > > > > > About smp-cache > > > > > > =============== > > > > > > > > > > > > The API design has been discussed heavily in [3]. > > > > > > > > > > > > Now, smp-cache is implemented as a array integrated in > > > > > > -machine. Though -machine currently can't support JSON > > > > > > format, this is the one of the directions of future. > > > > > > > > > > > > An example is as follows: > > > > > > > > > > > > smp_cache=smp-cache.0.cache=l1i,smp-cache.0.topology=core,smp-cache.1.cache=l1d,smp-cache.1.topology=core,smp-cache.2.cache=l2,smp-cache.2.topology=module,smp-cache.3.cache=l3,smp-cache.3.topology=die > > > > > > > > > > > > "cache" specifies the cache that the properties will be > > > > > > applied on. This field is the combination of cache level and > > > > > > cache type. Now it supports "l1d" (L1 data cache), "l1i" (L1 > > > > > > instruction cache), "l2" (L2 unified cache) and "l3" (L3 > > > > > > unified cache). > > > > > > > > > > > > "topology" field accepts CPU topology levels including > > > > > > "thread", "core", "module", "cluster", "die", "socket", > > > > > > "book", "drawer" and a special value "default". > > > > > > > > > > Looks good; just one thing, does "thread" make sense? I think > > > > > that it's almost by definition that threads within a core share > > > > > all caches, but maybe I'm missing some hardware configurations. > > > > > > > > > > > > > Hi Paolo, merry Christmas. Yes, AFAIK, there's no hardware has > > > > thread level cache. > > > > > > Hi Zhao and Paolo, > > > > > > While the example looks OK to me, and makes sense. But would be > > > curious to know more scenarios where I can legitimately see benefit > > > there. > > > > > > I am wrestling with this point on ARM too. If I were to > > > have device trees describing caches in a way that threads get their > > > own private caches then this would not be possible to be > > > described via device tree due to spec limitations (+CCed Rob) if I > > > understood correctly. > > > > You asked me for the opposite though, and I described how you can > > share the cache. If you want a cache per thread, then you probably > > want a node per thread. > > > > Rob > > > > Hi Rob, > > That's right, I made the mistake in my prior message, and you recalled > correctly. I wanted shared caches between two threads, though I have > missed your answer before, just found it. > Thank you all! Alireza, do you know how to configure arm node through QEMU options? However, IIUC, arm needs more effort to configure cache per thread (by configuring node topology)...In that case, since no one has explicitly requested the need for cache per thread, I can disable cache per thread for now. I can return an error for this scenario during the general smp-cache option parsing (in the future, if there is a real need, it can be easily re-enabled). Will drop cache per thread in the next version. Thanks, Zhao
