Hi Tony, On 3/18/2024 3:00 PM, Luck, Tony wrote: >> Perhaps ... in this case it may make things easier to understand if >> those "mon_NODE_*" directories are sub-directories of the appropriate >> "mon_L3_*" directories. > > Reinette, > > Like this? > > $ tree mon_data/ > mon_data/ > ├── mon_L3_00 > │ ├── llc_occupancy > │ ├── mbm_local_bytes > │ ├── mbm_total_bytes > │ ├── mon_NODE_00 > │ │ ├── llc_occupancy > │ │ ├── mbm_local_bytes > │ │ └── mbm_total_bytes > │ └── mon_NODE_01 > │ ├── llc_occupancy > │ ├── mbm_local_bytes > │ └── mbm_total_bytes > └── mon_L3_01 > ├── llc_occupancy > ├── mbm_local_bytes > ├── mbm_total_bytes > ├── mon_NODE_02 > │ ├── llc_occupancy > │ ├── mbm_local_bytes > │ └── mbm_total_bytes > └── mon_NODE_03 > ├── llc_occupancy > ├── mbm_local_bytes > └── mbm_total_bytes > Yes. Pro: * This is familiar to users when compared to existing CTRL_MON group counts that are the sum of the MON groups within it. * Users continue to see the clear connection between files listed in /sys/fs/resctrl/info/L3_MON/mon_features found in "mon_L3*" directories. * If I understand correctly it also would continue to be useful to Arm [1] while not breaking existing user space since the mon_L3* counts continue to reflect the entire L3 resource. * This addresses your comment of maintaining the detailed information from each SNC node. * I do assume that if there is only one SNC node per L3 cache then those mon_NODE_* directories will not be present and, to address the issue that triggered this thread, user space can use presence of multiple "mon_NODE_*" directories per cache instance to know if SNC is enabled. Con: * Unclear how this may need to change if/when SNC becomes architectural. * Continues to "muddy" the naming of the directories: mon_<resource>_<id> vs mon_<scope>_<id>. This cannot be turned into agreement with user space where first directory is mon_<resource>_<id> and second directory is mon_<scope>_<id> because then we would need to have, for example, mon_L3_00/mon_L3_00 where the first directory is for the resource and the second is for the scope, which appears redundant. * Things may get confusing if there is ever a "node" resource. This is starting to look like an interface that "checks" all the requirements I've seen so far. Looking at the "con" it is difficult for me to see how doing something like this now may cause frustrations later. Reinette [1] https://lore.kernel.org/lkml/88430722-67b3-4f7d-8db2-95ee52b6f0b0@xxxxxxx/
