[PATCH 0/1] fs/resctrl: Show domain CPU list in schema output

[PATCH 0/1] fs/resctrl: Show domain CPU list in schema output

[Aaron Tomlin]

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

[PATCH 1/1] fs/resctrl: Show domain CPU list in schema output

[Aaron Tomlin]

The resctrl schemata output currently displays only the domain ID and
its configured value e.g., "0=ffff". This format lacks visibility into
the underlying topology, making it difficult for users to quickly verify
which logical CPUs belong to the listed resource domain.

This patch improves visibility and aids in validation when configuring
or monitoring resource groupings, changing the output format from
"0=ffff" to "0=ffff,0-15".

Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
---
 fs/resctrl/ctrlmondata.c | 4 +++-
 fs/resctrl/rdtgroup.c    | 4 ++--
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
index 0d0ef54fc4de..5ad12d15b350 100644
--- a/fs/resctrl/ctrlmondata.c
+++ b/fs/resctrl/ctrlmondata.c
@@ -402,7 +402,9 @@ static void show_doms(struct seq_file *s, struct resctrl_schema *schema, int clo
 			ctrl_val = resctrl_arch_get_config(r, dom, closid,
 							   schema->conf_type);
 
-		seq_printf(s, schema->fmt_str, dom->hdr.id, ctrl_val);
+		seq_printf(s, schema->fmt_str, dom->hdr.id, ctrl_val,
+			   cpumask_pr_args(&dom->hdr.cpu_mask));
+
 		sep = true;
 	}
 	seq_puts(s, "\n");
diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index 0320360cd7a6..cec89ae549e0 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -2661,10 +2661,10 @@ static int schemata_list_add(struct rdt_resource *r, enum resctrl_conf_type type
 
 	switch (r->schema_fmt) {
 	case RESCTRL_SCHEMA_BITMAP:
-		s->fmt_str = "%d=%x";
+		s->fmt_str = "%d=%x,%*pbl";
 		break;
 	case RESCTRL_SCHEMA_RANGE:
-		s->fmt_str = "%d=%u";
+		s->fmt_str = "%d=%u,%*pbl";
 		break;
 	}
 
-- 
2.51.0

RE: [PATCH 0/1] fs/resctrl: Show domain CPU list in schema output

[Luck, Tony]

> 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

Re: [PATCH 0/1] fs/resctrl: Show domain CPU list in schema output

[Aaron Tomlin]

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

Re: [PATCH 0/1] fs/resctrl: Show domain CPU list in schema output

[Dave Martin]

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

Re: [PATCH 0/1] fs/resctrl: Show domain CPU list in schema output

[Aaron Tomlin]

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