Hi Markus, On Thu, Jul 25, 2024 at 10:51:49AM +0200, Markus Armbruster wrote: [snip] > >> What's the use case? The commit messages don't tell. > > > > i386 has the default cache topology model: l1 per core/l2 per core/l3 > > per die. > > > > Cache topology affects scheduler performance, e.g., kernel's cluster > > scheduling. > > > > Of course I can hardcode some cache topology model in the specific cpu > > model that corresponds to the actual hardware, but for -cpu host/max, > > the default i386 cache topology model has no flexibility, and the > > host-cpu-cache option doesn't have enough fine-grained control over the > > cache topology. > > > > So I want to provide a way to allow user create more fleasible cache > > topology. Just like cpu topology. > > > So the use case is exposing a configurable cache topology to the guest > in order to increase performance. Performance can increase when the > configured virtual topology is closer to the physical topology than a > default topology would be. This can be the case with CPU host or max. > > Correct? Yes! That's x86 use case. Jonathan also helped me explain his ARM use case. > >> Why does that use case make no sense without SMP? > > > > As the example I mentioned, for Intel hyrbid architecture, P cores has > > l2 per core and E cores has l2 per module. Then either setting the l2 > > topology level as core nor module, can emulate the real case. > > > > Even considering the more extreme case of Intel 14th MTL CPU, where > > some E cores have L3 and some don't even have L3. As well as the last > > time you and Daniel mentioned that in the future we could consider > > covering more cache properties such as cache size. But the l3 size can > > be different in the same system, like AMD's x3D technology. So > > generally configuring properties for @name in a list can't take into > > account the differences of heterogeneous caches with the same @name. > > > > Hope my poor english explains the problem well. :-) > > I think I understand why you want to configure caches. My question was > about the connection to SMP. > > Say we run a guest with a single core, no SMP. Could configuring caches > still be useful then? No, for this case the CPU topology (of x86) would be 1 core per module, 1 module per die, 1 die per socket. Then this core actually owns the l1/l2/l3. > >> Can the same @name occur multiple times? Documentation doesn't tell. > >> If yes, what does that mean? > > > > Yes, this means the later one will override the previous one with the same > > name. > > Needs documenting. > > If you make it an error, you don't have to document it :) OK! > >> Say we later add value "l1" for unified level 1 cache. Would "l1" then > >> conflict with "l1d" and "l1u"? > > > > Yes, we should check in smp/machine code and ban l1 and l1i/l1d at the > > same time. This check I suppose is easy to add. > > > >> May @topo be "invalid"? Documentation doesn't tell. If yes, what does > >> that mean? > > > > Yes, just follow the intel's spec, invalid means the current topology > > information is invalid, which is used to encode x86 CPUIDs. So when I > > move this level to qapi, I just keeped this. Otherwise, I need to > > re-implement the i386 specific invalid level. > > I'm afraid I don't understand what is supposed to happen when I tell > QEMU to make a cache's topology invalid. Currently this series doesn't allow users to set invalid, if they do, QEMU reports an error. So this invalid is just for QEMU internal use. Do you think it's okay? [snip] > > Ah, I also considerred this. I didn't use "type" because people usually > > uses cache type to indicate INSTRUCTION/DATA/UNIFIED and cache level to > > indicate LEVEL 1/LEVEL 2/LEVEL 3. The enumeration here is a combination of > > type+level. So I think it's better to avoid the type term. > > SmpCacheLevelAndType is quite a mouthful. Better name! Thanks! Regards, Zhao
