add l3Cache node level to topology

[wongchar]

Hello!

I would like to propose L3 cache restriction/affinity in the NRI Topology Aware resource policy.
The existing die node level supports resource optimization for AMD EPYC SKUs where the die contains a single L3 cache.

However, there are some SKUs of AMD EPYC that will contain up to two L3 caches on a single die.
AMD refers to these L3 cache core groupings as a Core Complex (CCX) with up to two CCXs on a Core Complex Die (CCD).

The other motivation is to extend the unlimitedBurstable feature to the L3 Cache level as well.

Please let me know your thoughts

[klihub]

Hello!

I would like to propose L3 cache restriction/affinity in the NRI Topology Aware resource policy. The existing die node level supports resource optimization for AMD EPYC SKUs where the die contains a single L3 cache.

However, there are some SKUs of AMD EPYC that will contain up to two L3 caches on a single die. AMD refers to these L3 cache core groupings as a Core Complex (CCX) with up to two CCXs on a Core Complex Die (CCD).

The other motivation is to extend the unlimitedBurstable feature to the L3 Cache level as well.

Please let me know your thoughts

@wongchar Thank you ! We are definitely interested to get this merged. But I think it would be good to add e2e test cases for verification. Would you be able to provide a sample sysfs dump or the relevant subset of it for such a HW. It would help check how easily we could add such tests.

We probably cannot emulate this directly by qemu, but this is not the only such feature and we already have some environment based overrides in the sysfs/detection code specifically to be able to fake and test things which can't be emulate properly.

[wongchar]

amd-128c-8l3-sysfs.tar.gz

Agreed, attached is the sysfs of an epyc processor (8534P) with two L3 caches per die. (Single numa, single socket, smt-enabled).

Happy to help add e2e tests based on what is most cohesive with the existing codebase :)