Hi Tony,
On 3/7/2024 9:57 AM, Luck, Tony wrote:
SNC2 enabled:
$ cat /sys/fs/resctrl/info/L3_mon/ snc_nodes_per_l3_cache 2
This would be useful. I believe "SNC" is architecture specific? What if the file always exists and is named "nodes_per_l3_cache"?
I assume that the internals of handling more nodes per L3 cache should be hidden from user space and it should not be necessary for user space to know if this is because of SNC or potentially some other mechanism on another platform?
I think that may reduce fragmentation of resctrl .... not having resctrl look so different on different architectures but maintains the promise of a generic interface.
I am not sure if this is specific to monitoring though, why not host file in /sys/fs/resctrl/info/L3 ?
Reinette,
On the name change - sure. It doesn't need the "snc_" prefix.
The Intel implementation of SNC has far more effect on monitoring than on control. The user can read separate cache occupancy and memory bandwidth values for each SNC node. But cache allocation bitmasks and memory throttling still have a single control point for each L3 cache instance, not for each node. There are still some impacts on control, e.g. each bit in a CAT bitmask represents less actual space in the L3 cache.
I understand the impact but I am trying to view this conceptually. The info directory exists to "contain information about the enabled resources" (as per documentation) and it seems appropriate to make this a property of the L3 resource.
Maybe move it to the top level of the info/ directory:
$ cat /sys/fs/resctrl/info/nodes_per_l3_cache 3
Thinking about it even differently. The goal is to give information to userspace so we need to think about what would help user space? For example, what if there is a file in info that shows which CPUs are associated with each domain?
Reinette