[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7f15a700-f23a-48f9-b335-13ea1735ad84@intel.com>
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/
Powered by blists - more mailing lists