Hi Babu,

Following up on your work in the x86,fs/resctrl: Support L3 Smart Data
Cache Injection Allocation Enforcement (SDCIAE) series, I've prepared a
small enhancement.

The current resctrl schemata output provides only the domain ID and value
(e.g., 0=ffff). This patch updates the schema format to include the
underlying topology, making it easier for users to correlate the resource
domain with its assigned logical CPUs.

The output changes from "0=ffff" to "0=ffff,0-15".

Please let me know your thoughts.


Aaron Tomlin (1):
  fs/resctrl: Show domain CPU list in schema output

 fs/resctrl/ctrlmondata.c | 4 +++-
 fs/resctrl/rdtgroup.c    | 4 ++--
 2 files changed, 5 insertions(+), 3 deletions(-)

-- 
2.51.0

> The current resctrl schemata output provides only the domain ID and value
> (e.g., 0=ffff). This patch updates the schema format to include the
> underlying topology, making it easier for users to correlate the resource
> domain with its assigned logical CPUs.
>
> The output changes from "0=ffff" to "0=ffff,0-15".
>
> Please let me know your thoughts.

1) You'd also need to change the "write" path for the schemata file
(treating the CPU list as read-only).

2) This would break user ABI, so is not going to happen.

Users can see the association between the domain numbers and
CPUs in sysfs.

$ cat /sys/devices/system/cpu/cpu0/cache/index3/id
0
$ cat /sys/devices/system/cpu/cpu0/cache/index3/shared_cpu_list
0-27

Maybe not as convenient as a direct read-out in the schemata file.
But the information is easily accessible.

-Tony

On Fri, Oct 31, 2025 at 07:03:15PM +0000, Luck, Tony wrote:
> 1) You'd also need to change the "write" path for the schemata file
> (treating the CPU list as read-only).
> 
> 2) This would break user ABI, so is not going to happen.

Hi Tony,

Thank you for following up.

If I understand correctly, parse_cbm() and parse_bw() would return -EINVAL
if the user incorrectly included the CPU list, no?

I suspect the issue is if one can read something from a file, one should be
able to write the same thing back and have it either succeed or process
only the valid parts. I agree maintaining ABI compatibility while allowing
the new verbose output on the read path is not ideal.

> Users can see the association between the domain numbers and
> CPUs in sysfs.
> 
> $ cat /sys/devices/system/cpu/cpu0/cache/index3/id
> 0
> $ cat /sys/devices/system/cpu/cpu0/cache/index3/shared_cpu_list
> 0-27
> 
> Maybe not as convenient as a direct read-out in the schemata file.
> But the information is easily accessible.

No, using the above to establish the association is absolutely fine. 


Kind regards,

-- 
Aaron Tomlin

Hi,

On Fri, Oct 31, 2025 at 05:25:41PM -0400, Aaron Tomlin wrote:
> On Fri, Oct 31, 2025 at 07:03:15PM +0000, Luck, Tony wrote:
> > 1) You'd also need to change the "write" path for the schemata file
> > (treating the CPU list as read-only).
> > 
> > 2) This would break user ABI, so is not going to happen.
> 
> Hi Tony,
> 
> Thank you for following up.
> 
> If I understand correctly, parse_cbm() and parse_bw() would return -EINVAL
> if the user incorrectly included the CPU list, no?
> 
> I suspect the issue is if one can read something from a file, one should be
> able to write the same thing back and have it either succeed or process
> only the valid parts. I agree maintaining ABI compatibility while allowing
> the new verbose output on the read path is not ideal.

Partly, but existing software that reads the file is also likely to get
confused by the new syntax appearing when reading the file.

(Nothing requires the data read out from the file to resemble what is
written in, though it certainly less surprising for userspace if it
looks the same, and if the data read will be accepted, with the same
meaning, when written back in.)


Note, using a comma as a delimiter may be problematic with %pbl-style
lists, since if the list is discontiguous then the pretty-printed list
can contain commas too.

On my system:

$ cat /sys/devices/system/cpu/cpu0/cache/index3/shared_cpu_list
-->
0-15,32-47

> > Users can see the association between the domain numbers and
> > CPUs in sysfs.
> > 
> > $ cat /sys/devices/system/cpu/cpu0/cache/index3/id
> > 0
> > $ cat /sys/devices/system/cpu/cpu0/cache/index3/shared_cpu_list
> > 0-27
> > 
> > Maybe not as convenient as a direct read-out in the schemata file.
> > But the information is easily accessible.
> 
> No, using the above to establish the association is absolutely fine. 

In theory, a alternate write syntax could be supported without
breaking compatibility, say:

	cpu<n>=<mask>

instead of

	<domain>=<main>

as a alternative way of referring to the control domain containing
CPU <n>.

But I think that this may do as much harm as good -- if the user
doesn't understand the topology, trying to program the masks on a per-
CPU basis isn't going to work do what the user wants anyway.

So I think we'd want a good argument as to why this is needed / useful.

Cheers
---Dave

On Mon, Nov 03, 2025 at 04:19:05PM +0000, Dave Martin wrote:
> Partly, but existing software that reads the file is also likely to get
> confused by the new syntax appearing when reading the file.

Hi Dave,

Thank you for your feedback.

I agree.

> Note, using a comma as a delimiter may be problematic with %pbl-style
> lists, since if the list is discontiguous then the pretty-printed list
> can contain commas too.

Fair point.

> In theory, a alternate write syntax could be supported without
> breaking compatibility, say:
> 
> 	cpu<n>=<mask>
> 
> instead of
> 
> 	<domain>=<main>
> 
> as a alternative way of referring to the control domain containing
> CPU <n>.
> 
> But I think that this may do as much harm as good -- if the user
> doesn't understand the topology, trying to program the masks on a per-
> CPU basis isn't going to work do what the user wants anyway.
> 
> So I think we'd want a good argument as to why this is needed / useful.

Understood. What Tony mentioned previously is sufficient; I should have
reviewed drivers/base/cacheinfo.c before posting.


Kind regards,
-- 
Aaron Tomlin