linux-kernel - Re: [PATCH 4/4] selftests/resctrl: Adjust SNC support messages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 18 Mar 2024 15:43:28 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: "Luck, Tony" <tony.luck@...el.com>, James Morse <james.morse@....com>
CC: "Wieczor-Retman, Maciej" <maciej.wieczor-retman@...el.com>, "Yu, Fenghua"
	<fenghua.yu@...el.com>, Shuah Khan <shuah@...nel.org>,
	"ilpo.jarvinen@...ux.intel.com" <ilpo.jarvinen@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH 4/4] selftests/resctrl: Adjust SNC support messages

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@arm.com/