Hi Tejus, > Thank you for this improvement! I see that even within the SPR-SP line of > Processors, the cache sizes vary across different models. What happens for > an instance when a processor only has 37.5 MiB of L3 per socket, but the CPU > Model exposes 60 MiB of L3 to the VM?
AFAIK, the Linux scheduler doesn't take cache size into account, so generally speaking, I think there's no impat on Linux. If user space apps don't care about this info, then there's no problem. However, I've met some cases where certain customers prefer that the named cpu model also become closer to real silicon (e.g. current cache size). The advantage of this is that an app that works fine on real silicon is more likely to run normally in a Guest environment... Because nobody can ensure that no user space app care about cache size at all. And it's also unknown if there will be other OSes that depend on the cache size (although I think it should be fine, after all, current x86 only supports smp machines). In contrast, the 0x1f example is more typical. By SDM, 0x1f is only optional, and if 0x1f is not available, the one should check 0xb. However, in Mishra's case, his windows only relies on 0x1f, so making the named CPU model and the real silicon alignable is a better way of avoiding all sorts of incompatibilities. Thanks, Zhao
