x86,fs/resctrl: Support L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE)

Smart Data Cache Injection (SDCI) is a mechanism that enables direct insertion of data from I/O devices into the L3 cache. By directly caching data from I/O devices rather than first storing the I/O data in DRAM, SDCI reduces demands on DRAM bandwidth and reduces latency to the processor consuming the I/O data.

The SDCIAE (SDCI Allocation Enforcement) PQE feature allows system software to control the portion of the L3 cache used for SDCI.

When enabled, SDCIAE forces all SDCI lines to be placed into the L3 cache partitions identified by the highest-supported L3_MASK_n register, where n is the maximum supported CLOSID.

Add CPUID feature bit that can be used to configure SDCIAE.

The SDCIAE feature details are documented in APM [1] available from [2].
[1] AMD64 Architecture Programmer's Manual Volume 2: System Programming Publication # 24593 Revision 3.41 section 19.4.7 L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE)

Link https://bugzilla.kernel.org/show_bug.cgi?id=206537 # [2]

Signed-off-by Babu Moger <[email protected]>

Acked-by Borislav Petkov (AMD) <[email protected]>

Reviewed-by Reinette Chatre <[email protected]>

---

Hi Babu,

(Just highlighting some changelog formatting that was needed for ABMC changelogs.)

Quoted 13 lines · Babu Moger

Smart Data Cache Injection (SDCI) is a mechanism that enables direct insertion of data from I/O devices into the L3 cache. By directly caching data from I/O devices rather than first storing the I/O data in DRAM, SDCI reduces demands on DRAM bandwidth and reduces latency to the processor consuming the I/O data.

The SDCIAE (SDCI Allocation Enforcement) PQE feature allows system software to control the portion of the L3 cache used for SDCI.

When enabled, SDCIAE forces all SDCI lines to be placed into the L3 cache partitions identified by the highest-supported L3_MASK_n register, where n is the maximum supported CLOSID.

Quoted 6 lines

Add CPUID feature bit that can be used to configure SDCIAE.

The SDCIAE feature details are documented in APM [1] available from [2].
[1] AMD64 Architecture Programmer's Manual Volume 2: System Programming Publication # 24593 Revision 3.41 section 19.4.7 L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE)

Compare with how indentation of ABMC "x86,fs/resctrl: Implement resctrl_arch_config_cntr() to assign a counter with ABMC" was changed during merge.

[1] AMD64 Architecture Programmer's Manual Volume 2: System Programming Publication # 24593 Revision 3.41 section 19.4.7 L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE)

(also applies to patch #4)

Quoted 3 lines

Link https://bugzilla.kernel.org/show_bug.cgi?id=206537 # [2]

Please place "Link:" tag at end to reduce needed adjustments during merge.

Add the command line option to enable or disable the new resctrl feature L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE).

Signed-off-by Babu Moger <[email protected]>

---

Hi Babu,

Quoted 2 lines · Babu Moger

Add the command line option to enable or disable the new resctrl feature L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE).

Since SDCIAE is the architecture specific feature while the generic resctrl feature is "io_alloc" I think it will be more accurate to say something similar to the ABMC changelog:
Add a kernel command-line parameter to enable or disable the exposure of the L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE) hardware feature to resctrl.

Quoted 3 lines

Signed-off-by Babu Moger <[email protected]>

---

With changelog change:

| Reviewed-by: Reinette Chatre <[email protected]>

Smart Data Cache Injection (SDCI) is a mechanism that enables direct insertion of data from I/O devices into the L3 cache. It can reduce the demands on DRAM bandwidth and reduces latency to the processor consuming the I/O data.

Introduce cache resource property "io_alloc_capable" that an architecture can set if a portion of the cache can be allocated for I/O traffic.

Set this property on x86 systems that support SDCIAE (L3 Smart Data Cache Injection Allocation Enforcement). This property is set only for the L3 cache resource on systems that support SDCIAE.

Signed-off-by Babu Moger <[email protected]>

Reviewed-by Reinette Chatre <[email protected]>

---

Hi Babu,

Quoted 4 lines · Babu Moger

Smart Data Cache Injection (SDCI) is a mechanism that enables direct insertion of data from I/O devices into the L3 cache. It can reduce the demands on DRAM bandwidth and reduces latency to the processor consuming the I/O data.

This copy&pasted text found in cover letter and patch 1 and now here seems to be the type of annoying repetitive text that Boris referred to [1]. Looking at this changelog again it may also be confusing to start with introduction of one feature (SDCI), but end with another SDCIAE.

Here is a changelog that attempts to address issues, please feel free to improve:

AMD's SDCIAE (SDCI Allocation Enforcement) PQE feature enables system software to control the portions of L3 cache used for direct insertion of data from I/O devices into the L3 cache.

Introduce a generic resctrl cache resource property "io_alloc_capable" as the first part of the new "io_alloc" resctrl feature that will support AMD's
SDCIAE. Any architecture can set a cache resource as "io_alloc_capable" if a
portion of the cache can be allocated for I/O traffic.

Set the "io_alloc_capable" property for the L3 cache resource on x86 (AMD) systems that support SDCIAE.

Quoted 10 lines

Introduce cache resource property "io_alloc_capable" that an architecture can set if a portion of the cache can be allocated for I/O traffic.

Set this property on x86 systems that support SDCIAE (L3 Smart Data Cache Injection Allocation Enforcement). This property is set only for the L3 cache resource on systems that support SDCIAE.

Signed-off-by Babu Moger <[email protected]>

Reviewed-by Reinette Chatre <[email protected]>

---

Reinette

[1] https://lore.kernel.org/lkml/20250911150850.GAaMLmAoi5fTIznQzY@fat_crate.local/

"io_alloc" enables direct insertion of data from I/O devices into the cache.

On AMD systems, "io_alloc" feature is backed by L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE). Change SDCIAE state by setting (to enable) or clearing (to disable) bit 1 of MSR L3_QOS_EXT_CFG on all

logical processors within the cache domain.

Introduce architecture-specific call to enable and disable the feature.

The SDCIAE feature details are documented in APM [1] available from [2].
[1] AMD64 Architecture Programmer's Manual Volume 2: System Programming Publication # 24593 Revision 3.41 section 19.4.7 L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE)

Link https://bugzilla.kernel.org/show_bug.cgi?id=206537 # [2]

Signed-off-by Babu Moger <[email protected]>

Reviewed-by Reinette Chatre <[email protected]>

---

arch/x86/kernel/cpu/resctrl/ctrlmondata.c +16 -0

+	list_for_each_entry(d, &r->ctrl_domains, hdr.list)
+		on_each_cpu_mask(&d->hdr.cpu_mask, resctrl_sdciae_set_one_amd, &enable, 1);
+}
+
+int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable)
+{
+	struct rdt_hw_resource *hw_res = resctrl_to_arch_res(r);
+
+	if (hw_res->r_resctrl.cache.io_alloc_capable &&
+	    hw_res->sdciae_enabled != enable) {
+		_resctrl_sdciae_enable(r, enable);
+		hw_res->sdciae_enabled = enable;
+	}
+
+	return 0;
+}

arch/x86/kernel/cpu/resctrl/internal.h +0 -0

index 5e3c41b36437..70f5317f1ce4 100644

Hi Babu,

Quoted 2 lines · Babu Moger

"io_alloc" enables direct insertion of data from I/O devices into the cache.

(repetition)

Quoted 1 line

Quoted 3 lines

On AMD systems, "io_alloc" feature is backed by L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE). Change SDCIAE state by setting (to enable) or clearing (to disable) bit 1 of MSR L3_QOS_EXT_CFG on all

Did you notice Boris's touchup on ABMC "x86/resctrl: Add data structures and definitions for ABMC assignment"? This should be MSR_IA32_L3_QOS_EXT_CFG (also needed in patch self, more below)

Quoted 8 lines

logical processors within the cache domain.

Introduce architecture-specific call to enable and disable the feature.

The SDCIAE feature details are documented in APM [1] available from [2].
[1] AMD64 Architecture Programmer's Manual Volume 2: System Programming Publication # 24593 Revision 3.41 section 19.4.7 L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE)

(same comment as patch #1)

Changelog that aims to address feeback received in ABMC series, please feel free to improve:
"io_alloc" is the generic name of the new resctrl feature that enables system software to configure the portion of cache allocated for I/O traffic. On AMD systems, "io_alloc" resctrl feature is backed by AMD's L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE).

Introduce the architecture-specific functions that resctrl fs should call to enable, disable, or check status of the "io_alloc" feature. Change SDCIAE state by setting (to enable) or clearing (to disable) bit 1 of MSR_IA32_L3_QOS_EXT_CFG on all logical processors within the cache domain.

The SDCIAE feature details are documented in APM [1] available from [2].
[1] AMD64 Architecture Programmer's Manual Volume 2: System Programming Publication # 24593 Revision 3.41 section 19.4.7 L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE)

Quoted 2 lines

Link https://bugzilla.kernel.org/show_bug.cgi?id=206537 # [2]

(please move to end of tags)

Quoted 4 lines

Signed-off-by Babu Moger <[email protected]>

Reviewed-by Reinette Chatre <[email protected]>

---

...

arch/x86/kernel/cpu/resctrl/ctrlmondata.c u32 resctrl_arch_get_config(struct rdt_resource *r, struct rdt_ctrl_domain *d, · line 117

Quoted 8 lines

arch/x86/kernel/cpu/resctrl/ctrlmondata.c +8 -0

+static void _resctrl_sdciae_enable(struct rdt_resource *r, bool enable)
+{
+	struct rdt_ctrl_domain *d;
+
+	/* Walking r->ctrl_domains, ensure it can't race with cpuhp */
+	lockdep_assert_cpus_held();
+
+	/* Update L3_QOS_EXT_CFG MSR on all the CPUs in all domains */

"L3_QOS_EXT_CFG MSR" -> MSR_IA32_L3_QOS_EXT_CFG

(to match touchups needed to ABMC series)

Quoted 25 lines

arch/x86/kernel/cpu/resctrl/ctrlmondata.c +16 -0

+	list_for_each_entry(d, &r->ctrl_domains, hdr.list)
+		on_each_cpu_mask(&d->hdr.cpu_mask, resctrl_sdciae_set_one_amd, &enable, 1);
+}
+
+int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable)
+{
+	struct rdt_hw_resource *hw_res = resctrl_to_arch_res(r);
+
+	if (hw_res->r_resctrl.cache.io_alloc_capable &&
+	    hw_res->sdciae_enabled != enable) {
+		_resctrl_sdciae_enable(r, enable);
+		hw_res->sdciae_enabled = enable;
+	}
+
+	return 0;
+}

arch/x86/kernel/cpu/resctrl/internal.h +0 -0

index 5e3c41b36437..70f5317f1ce4 100644
@@ -37,6 +37,9 @@ struct arch_mbm_state {
  	u64	prev_msr;
  };
 

arch/x86/kernel/cpu/resctrl/internal.h struct arch_mbm_state { · line 40

Quoted 1 line

arch/x86/kernel/cpu/resctrl/internal.h +1 -0

+/* Setting bit 1 in L3_QOS_EXT_CFG enables the SDCIAE feature. */

"L3_QOS_EXT_CFG" -> MSR_IA32_L3_QOS_EXT_CFG

"io_alloc" feature in resctrl allows direct insertion of data from I/O devices into the cache.

Introduce the 'io_alloc' resctrl file to indicate the support for the feature.

Signed-off-by Babu Moger <[email protected]>

---

---
 Documentation/filesystems/resctrl.rst | 30 +++++++++++++++++++++++++++
 fs/resctrl/ctrlmondata.c              | 21 +++++++++++++++++++
 fs/resctrl/internal.h                 |  5 +++++
 fs/resctrl/rdtgroup.c                 | 24 ++++++++++++++++++++-
 4 files changed, 79 insertions(+), 1 deletion(-)

Documentation/filesystems/resctrl.rst +5 -0

index 4866a8a4189f..89aab17b00cb 100644
@@ -136,6 +136,36 @@ related to allocation:
 			"1":
 			      Non-contiguous 1s value in CBM is supported.
 
+"io_alloc":
+		"io_alloc" enables system software to configure the portion of
+		the cache allocated for I/O traffic. File may only exist if the
+		system supports this feature on some of its cache resources.
+

Documentation/filesystems/resctrl.rst +8 -0

+		The underlying implementation may reduce resources available to
+		general (CPU) cache allocation. See architecture specific notes
+		below. Depending on usage requirements the feature can be enabled
+		or disabled.
+
+		On AMD systems, io_alloc feature is supported by the L3 Smart
+		Data Cache Injection Allocation Enforcement (SDCIAE). The CLOSID for
+		io_alloc is the highest CLOSID supported by the resource. When

Hi Babu,

Quoted 5 lines · Babu Moger

"io_alloc" feature in resctrl allows direct insertion of data from I/O devices into the cache.

Introduce the 'io_alloc' resctrl file to indicate the support for the feature.

Changelog that aims to address feeback received in ABMC series (avoid repetition and document any non-obvious things), please feel free to improve:

Introduce the "io_alloc" resctrl file to the "info" area of a cache resource, for example /sys/fs/resctrl/info/L3/io_alloc. "io_alloc" indicates support for the "io_alloc" feature that allows direct insertion of data from I/O devices into the cache.

Restrict exposing support for "io_alloc" to the L3 resource that is the only resource where this feature can be backed by AMD's L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE). With that, the "io_alloc" file is only visible to user space if the L3 resource supports "io_alloc". Doing so makes the file visible for all cache resources though, for example also L2 cache (if it supports cache allocation). As a consequence, add capability for file to report expected "enabled" and "disabled", as well as "not supported".

Quoted 3 lines

Signed-off-by Babu Moger <[email protected]>

---

...

Quoted 25 lines

---
  Documentation/filesystems/resctrl.rst | 30 +++++++++++++++++++++++++++
  fs/resctrl/ctrlmondata.c              | 21 +++++++++++++++++++
  fs/resctrl/internal.h                 |  5 +++++
  fs/resctrl/rdtgroup.c                 | 24 ++++++++++++++++++++-
  4 files changed, 79 insertions(+), 1 deletion(-)

Documentation/filesystems/resctrl.rst +10 -0

index 4866a8a4189f..89aab17b00cb 100644
@@ -136,6 +136,36 @@ related to allocation:
  			"1":
  			      Non-contiguous 1s value in CBM is supported.
 
+"io_alloc":
+		"io_alloc" enables system software to configure the portion of
+		the cache allocated for I/O traffic. File may only exist if the
+		system supports this feature on some of its cache resources.
+
+			"disabled":
+			      Resource supports "io_alloc" but the feature is disabled.
+			      Portions of cache used for allocation of I/O traffic cannot
+			      be configured.
+			"enabled":

Documentation/filesystems/resctrl.rst related to allocation: · line 153

Quoted 5 lines

Documentation/filesystems/resctrl.rst +5 -0

+			      Portions of cache used for allocation of I/O traffic
+			      can be configured using "io_alloc_cbm".
+			"not supported":
+			      Support not available for this resource.
+

After trying to rework the changelogs I believe the portion of doc below is better suited for the next patch that adds support for enable/disable where CLOSIDs are relevant.

Quoted 9 lines

Documentation/filesystems/resctrl.rst +8 -0

+		The underlying implementation may reduce resources available to
+		general (CPU) cache allocation. See architecture specific notes
+		below. Depending on usage requirements the feature can be enabled
+		or disabled.
+
+		On AMD systems, io_alloc feature is supported by the L3 Smart
+		Data Cache Injection Allocation Enforcement (SDCIAE). The CLOSID for
+		io_alloc is the highest CLOSID supported by the resource. When

Documentation/filesystems/resctrl.rst related to allocation: · line 171

Quoted 10 lines

Documentation/filesystems/resctrl.rst +7 -0

+		io_alloc is enabled, the highest CLOSID is dedicated to io_alloc and
+		no longer available for general (CPU) cache allocation. When CDP is
+		enabled, io_alloc routes I/O traffic using the highest CLOSID allocated
+		for the instruction cache (L3CODE), making this CLOSID no longer
+		available for general (CPU) cache allocation for both the L3CODE and
+		L3DATA resources.
+
  Memory bandwidth(MB) subdirectory contains the following files
  with respect to allocation:
 

Reinette

"io_alloc" feature in resctrl enables direct insertion of data from I/O devices into the cache.

On AMD systems, when io_alloc is enabled, the highest CLOSID is reserved exclusively for I/O allocation traffic and is no longer available for general CPU cache allocation. Users are encouraged to enable it only when running workloads that can benefit from this functionality.

Since CLOSIDs are managed by resctrl fs, it is least invasive to make the "io_alloc is supported by maximum supported CLOSID" part of the initial resctrl fs support for io_alloc. Take care not to expose this use of CLOSID for io_alloc to user space so that this is not required from other architectures that may support io_alloc differently in the future.

Introduce user interface to enable/disable io_alloc feature. Check to verify the availability of CLOSID reserved for io_alloc, and initialize the CLOSID with a usable CBMs across all the domains.

Signed-off-by Babu Moger <[email protected]>

---

fs/resctrl/ctrlmondata.c +22 -0

+ssize_t resctrl_io_alloc_write(struct kernfs_open_file *of, char *buf,
+			       size_t nbytes, loff_t off)
+{
+	struct resctrl_schema *s = rdt_kn_parent_priv(of->kn);
+	struct rdt_resource *r = s->res;
+	char const *grp_name;
+	u32 io_alloc_closid;
+	bool enable;
+	int ret;
+
+	ret = kstrtobool(buf, &enable);
+	if (ret)
+		return ret;
+
+	cpus_read_lock();
+	mutex_lock(&rdtgroup_mutex);
+
+	rdt_last_cmd_clear();
+
+	if (!r->cache.io_alloc_capable) {
+		rdt_last_cmd_printf("io_alloc is not supported on %s\n", s->name);
+		ret = -ENODEV;

fs/resctrl/ctrlmondata.c +13 -0

+					    io_alloc_closid, grp_name ? grp_name : "another");
+			ret = -ENOSPC;
+			goto out_unlock;
+		}
+
+		ret = resctrl_io_alloc_init_cbm(s, io_alloc_closid);
+		if (ret) {
+			rdt_last_cmd_puts("Failed to initialize io_alloc allocations\n");
+			closid_free(io_alloc_closid);
+			goto out_unlock;
+		}
+	} else {
+		closid_free(io_alloc_closid);

Hi Babu,

Quoted 2 lines · Babu Moger

"io_alloc" feature in resctrl enables direct insertion of data from I/O devices into the cache.

(repetition)

Quoted 12 lines

On AMD systems, when io_alloc is enabled, the highest CLOSID is reserved exclusively for I/O allocation traffic and is no longer available for general CPU cache allocation. Users are encouraged to enable it only when running workloads that can benefit from this functionality.

Since CLOSIDs are managed by resctrl fs, it is least invasive to make the "io_alloc is supported by maximum supported CLOSID" part of the initial resctrl fs support for io_alloc. Take care not to expose this use of CLOSID for io_alloc to user space so that this is not required from other architectures that may support io_alloc differently in the future.

Quoted 3 lines

Introduce user interface to enable/disable io_alloc feature. Check to verify the availability of CLOSID reserved for io_alloc, and initialize the CLOSID with a usable CBMs across all the domains.

I think the flow will improve if above two paragraphs are swapped. This is also missing the non-obvious support for CDP. As mentioned in previous patch, if the related doc change is moved from patch 5 to here it can be handled together.

Trying to put it all together, please feel free to improve:

AMD's SDCIAE forces all SDCI lines to be placed into the L3 cache portions identified by the highest-supported L3_MASK_n register, where n is the maximum supported CLOSID.

To support AMD's SDCIAE, when io_alloc resctrl feature is enabled, reserve the highest CLOSID exclusively for I/O allocation traffic making it no longer available for general CPU cache allocation.

Introduce user interface to enable/disable io_alloc feature and encourage users to enable io_alloc only when running workloads that can benefit from this functionality. On enable, initialize the io_alloc CLOSID with all usable CBMs across all the domains.

Since CLOSIDs are managed by resctrl fs, it is least invasive to make "io_alloc is supported by maximum supported CLOSID" part of the initial resctrl fs support for io_alloc. Take care to minimally (only in error messages) expose this use of CLOSID for io_alloc to user space so that this is
not required from other architectures that may support io_alloc differently in the future.

When resctrl is mounted with "-o cdp" to enable code/data prioritization there are two L3 resources that can support I/O allocation: L3CODE and L3DATA. From resctrl fs perspective the two resources share a CLOSID and the architecture's available CLOSID are halved to support this.
The architecture's underlying CLOSID used by SDCIAE when CDP is enabled is the CLOSID associated with the L3CODE resource, but from resctrl's perspective there is only one CLOSID for both L3CODE and L3DATA. L3DATA is thus not usable for general (CPU) cache allocation nor I/O allocation. Keep the L3CODE and L3DATA I/O alloc status in sync to avoid any confusion to user space. That is, enabling io_alloc on L3CODE does so on L3DATA and vice-versa, and keep the I/O allocation CBMs of L3CODE and L3DATA in sync.

Quoted 3 lines

Signed-off-by Babu Moger <[email protected]>

---

...

Quoted 26 lines

fs/resctrl/ctrlmondata.c +26 -0

+ssize_t resctrl_io_alloc_write(struct kernfs_open_file *of, char *buf,
+			       size_t nbytes, loff_t off)
+{
+	struct resctrl_schema *s = rdt_kn_parent_priv(of->kn);
+	struct rdt_resource *r = s->res;
+	char const *grp_name;
+	u32 io_alloc_closid;
+	bool enable;
+	int ret;
+
+	ret = kstrtobool(buf, &enable);
+	if (ret)
+		return ret;
+
+	cpus_read_lock();
+	mutex_lock(&rdtgroup_mutex);
+
+	rdt_last_cmd_clear();
+
+	if (!r->cache.io_alloc_capable) {
+		rdt_last_cmd_printf("io_alloc is not supported on %s\n", s->name);
+		ret = -ENODEV;
+		goto out_unlock;
+	}
+
+	/* If the feature is already up to date, no action is needed. */

fs/resctrl/ctrlmondata.c int resctrl_io_alloc_show(struct kernfs_open_file *of, struct seq_file *seq, voi · line 776

Quoted 6 lines

fs/resctrl/ctrlmondata.c +6 -0

+	if (resctrl_arch_get_io_alloc_enabled(r) == enable)
+		goto out_unlock;
+
+	io_alloc_closid = resctrl_io_alloc_closid(r);
+	if (!resctrl_io_alloc_closid_supported(io_alloc_closid)) {
+		rdt_last_cmd_printf("io_alloc CLOSID (ctrl_hw_id) %d is not available\n",

%d -> %u ?

fs/resctrl/ctrlmondata.c int resctrl_io_alloc_show(struct kernfs_open_file *of, struct seq_file *seq, voi · line 786

Quoted 11 lines

fs/resctrl/ctrlmondata.c +10 -0

+				    io_alloc_closid);
+		ret = -EINVAL;
+		goto out_unlock;
+	}
+
+	if (enable) {
+		if (!closid_alloc_fixed(io_alloc_closid)) {
+			grp_name = rdtgroup_name_by_closid(io_alloc_closid);
+			WARN_ON_ONCE(!grp_name);
+			rdt_last_cmd_printf("CLOSID (ctrl_hw_id) %d for io_alloc is used by %s group\n",

%d -> %u ?

Quoted 14 lines

fs/resctrl/ctrlmondata.c +13 -0

+					    io_alloc_closid, grp_name ? grp_name : "another");
+			ret = -ENOSPC;
+			goto out_unlock;
+		}
+
+		ret = resctrl_io_alloc_init_cbm(s, io_alloc_closid);
+		if (ret) {
+			rdt_last_cmd_puts("Failed to initialize io_alloc allocations\n");
+			closid_free(io_alloc_closid);
+			goto out_unlock;
+		}
+	} else {
+		closid_free(io_alloc_closid);

fs/resctrl/ctrlmondata.c int resctrl_io_alloc_show(struct kernfs_open_file *of, struct seq_file *seq, voi · line 809

Quoted 10 lines

fs/resctrl/ctrlmondata.c +10 -0

+	}
+
+	ret = resctrl_arch_io_alloc_enable(r, enable);
+
+out_unlock:
+	mutex_unlock(&rdtgroup_mutex);
+	cpus_read_unlock();
+
+	return ret ?: nbytes;
+}

Reinette

The io_alloc feature in resctrl enables system software to configure the portion of the cache allocated for I/O traffic.

Add "io_alloc_cbm" resctrl file to display the Capacity Bit Masks (CBMs) that represent the portion of each cache instance allocated for I/O traffic.

The CBM interface file io_alloc_cbm resides in the info directory (e.g., /sys/fs/resctrl/info/L3/). Since the resource name is part of the path, it is not necessary to display the resource name as done in the schemata file. Pass the resource name to show_doms() and print it only if the name is valid. For io_alloc, pass NULL pointer to suppress printing the resource name.

When CDP is enabled, io_alloc routes traffic using the highest CLOSID associated with the L3CODE resource. To ensure consistent cache allocation behavior, the L3CODE and L3DATA resources are kept in sync. So, the

Capacity Bit Masks (CBMs) accessed through either L3CODE or L3DATA will reflect identical values.

Signed-off-by Babu Moger <[email protected]>

---

fs/resctrl/ctrlmondata.c +11 -0

@@ -807,3 +809,40 @@ ssize_t resctrl_io_alloc_write(struct kernfs_open_file *of, char *buf,
 
 	return ret ?: nbytes;
 }
+
+int resctrl_io_alloc_cbm_show(struct kernfs_open_file *of, struct seq_file *seq, void *v)
+{
+	struct resctrl_schema *s = rdt_kn_parent_priv(of->kn);
+	struct rdt_resource *r = s->res;
+	int ret = 0;
+
+	cpus_read_lock();
+	mutex_lock(&rdtgroup_mutex);
+
+	rdt_last_cmd_clear();

Hi Babu,

Quoted 2 lines · Babu Moger

The io_alloc feature in resctrl enables system software to configure the portion of the cache allocated for I/O traffic.

(repetitive)

Quoted 11 lines

Add "io_alloc_cbm" resctrl file to display the Capacity Bit Masks (CBMs) that represent the portion of each cache instance allocated for I/O traffic.

The CBM interface file io_alloc_cbm resides in the info directory (e.g., /sys/fs/resctrl/info/L3/). Since the resource name is part of the path, it is not necessary to display the resource name as done in the schemata file. Pass the resource name to show_doms() and print it only if the name is valid. For io_alloc, pass NULL pointer to suppress printing the resource name.

Related to changelog feedback received during ABMC series I think the portion that describes the code (from "Pass the resource name ..." to "printing the resource name"), is unnecessary since it can be seen by looking at the patch.

Quoted 5 lines

When CDP is enabled, io_alloc routes traffic using the highest CLOSID associated with the L3CODE resource. To ensure consistent cache allocation behavior, the L3CODE and L3DATA resources are kept in sync. So, the

I do not think the "To ensure consistent cache allocation behavior" is accurate. This is just to avoid the possible user space confusion if supporting the feature with L3CODE used for I/O allocation and L3DATA becomes unusable, no?

Also, this also needs to be in imperative tone.

Quoted 2 lines

Capacity Bit Masks (CBMs) accessed through either L3CODE or L3DATA will reflect identical values.

Attempt to put it together, please feel free to improve:

Introduce the "io_alloc_cbm" resctrl file to display the Capacity Bit Masks (CBMs) that represent the portions of each cache instance allocated for I/O traffic on a cache resource that supports the "io_alloc" feature.

io_alloc_cbm resides in the info directory of a cache resource, for example, /sys/fs/resctrl/info/L3/. Since the resource name is part of the path, it is not necessary to display the resource name as done in the schemata file.

When CDP is enabled, io_alloc routes traffic using the highest CLOSID associated with the L3CODE resource and that CLOSID becomes unusable for the L3DATA resource. The highest CLOSID of L3CODE and L3DATA resources will
be kept in sync to ensure consistent user interface. In preparation for this,
access the CBMs for I/O traffic through highest CLOSID of either L3CODE or L3DATA resource.

Quoted 3 lines

Signed-off-by Babu Moger <[email protected]>

---

..

Quoted 20 lines

fs/resctrl/ctrlmondata.c +16 -0

@@ -807,3 +809,40 @@ ssize_t resctrl_io_alloc_write(struct kernfs_open_file *of, char *buf,
 
  	return ret ?: nbytes;
  }
+
+int resctrl_io_alloc_cbm_show(struct kernfs_open_file *of, struct seq_file *seq, void *v)
+{
+	struct resctrl_schema *s = rdt_kn_parent_priv(of->kn);
+	struct rdt_resource *r = s->res;
+	int ret = 0;
+
+	cpus_read_lock();
+	mutex_lock(&rdtgroup_mutex);
+
+	rdt_last_cmd_clear();
+
+	if (!r->cache.io_alloc_capable) {
+		rdt_last_cmd_printf("io_alloc is not supported on %s\n", s->name);
+		ret = -ENODEV;
+		goto out_unlock;

fs/resctrl/ctrlmondata.c ssize_t resctrl_io_alloc_write(struct kernfs_open_file *of, char *buf, · line 832

Quoted 5 lines

fs/resctrl/ctrlmondata.c +5 -0

+	}
+
+	if (!resctrl_arch_get_io_alloc_enabled(r)) {
+		rdt_last_cmd_printf("io_alloc is not enabled on %s\n", s->name);
+		ret = -EINVAL;

The return code when io_alloc is not enabled is different between reading from (EINVAL) and writing to (ENODEV) io_alloc_cbm. Please be consistent.

fs/resctrl/ctrlmondata.c ssize_t resctrl_io_alloc_write(struct kernfs_open_file *of, char *buf, · line 838

Quoted 7 lines

fs/resctrl/ctrlmondata.c +6 -0

+		goto out_unlock;
+	}
+
+	/*
+	 * When CDP is enabled, resctrl_io_alloc_init_cbm() sets the same CBM for
+	 * both L3CODE and L3DATA of the highest CLOSID. As a result, the io_alloc

Not just during initialization, they are kept in sync during runtime also (when user writes to io_alloc_cbm). First sentence can perhaps just be
"When CDP is enabled the CBMs of the highest CLOSID of L3CODE
and L3DATA are kept in sync. As a result, ..."

parse_cbm() require resource group mode and CLOSID to validate the Capacity Bit Mask (CBM). It is passed via struct rdtgroup in struct rdt_parse_data.

The io_alloc feature also uses CBMs to indicate which portions of cache are allocated for I/O traffic. The CBMs are provided by user space and need to be validated the same as CBMs provided for general (CPU) cache allocation. parse_cbm() cannot be used as-is since io_alloc does not have rdtgroup context.

Pass the resource group mode and CLOSID directly to parse_cbm() via struct rdt_parse_data, instead of through the rdtgroup struct, to facilitate calling parse_cbm() to verify the CBM of the io_alloc feature.

Signed-off-by Babu Moger <[email protected]>

---

Hi Babu,

nit:
Subject: fs/resctrl: Modify struct rdt_parse_data to pass mode and CLOSID

Quoted 13 lines

parse_cbm() require resource group mode and CLOSID to validate the Capacity Bit Mask (CBM). It is passed via struct rdtgroup in struct rdt_parse_data.

The io_alloc feature also uses CBMs to indicate which portions of cache are allocated for I/O traffic. The CBMs are provided by user space and need to be validated the same as CBMs provided for general (CPU) cache allocation. parse_cbm() cannot be used as-is since io_alloc does not have rdtgroup context.

Pass the resource group mode and CLOSID directly to parse_cbm() via struct rdt_parse_data, instead of through the rdtgroup struct, to facilitate calling parse_cbm() to verify the CBM of the io_alloc feature.

Quoted 2 lines

Signed-off-by Babu Moger <[email protected]>

---

With Subject change:

| Reviewed-by: Reinette Chatre <[email protected]>

The io_alloc feature in resctrl enables system software to configure the portion of the cache allocated for I/O traffic. When supported, the io_alloc_cbm file in resctrl provides access to Capacity Bit Masks (CBMs) reserved for I/O devices.

Enable users to modify io_alloc CBMs (Capacity Bit Masks) via the

io_alloc_cbm resctrl file when io_alloc is enabled.

To ensure consistent cache allocation when CDP is enabled, the CBMs

written to either L3CODE or L3DATA are mirrored to the other, keeping both resource types synchronized.

Signed-off-by Babu Moger <[email protected]>

---

---
 Documentation/filesystems/resctrl.rst | 11 ++++
 fs/resctrl/ctrlmondata.c              | 93 +++++++++++++++++++++++++++
 fs/resctrl/internal.h                 |  3 +
 fs/resctrl/rdtgroup.c                 |  3 +-
 4 files changed, 109 insertions(+), 1 deletion(-)

Documentation/filesystems/resctrl.rst +0 -0

index 15e3a4abf90e..7e3eda324de5 100644
@@ -188,6 +188,17 @@ related to allocation:
 			# cat /sys/fs/resctrl/info/L3/io_alloc_cbm

Documentation/filesystems/resctrl.rst +3 -0

+			# cat /sys/fs/resctrl/info/L3/io_alloc_cbm
+			0=00ff;1=000f
+
 		When CDP is enabled "io_alloc_cbm" associated with the DATA and CODE
 		resources may reflect the same values. For example, values read from and
 		written to /sys/fs/resctrl/info/L3DATA/io_alloc_cbm may be reflected by

fs/resctrl/ctrlmondata.c +22 -0

index a4e861733a95..791ecb559b50 100644
@@ -848,3 +848,96 @@ int resctrl_io_alloc_cbm_show(struct kernfs_open_file *of, struct seq_file *seq,
 	cpus_read_unlock();
 	return ret;
 }
+
+static int resctrl_io_alloc_parse_line(char *line,  struct rdt_resource *r,
+				       struct resctrl_schema *s, u32 closid)
+{
+	enum resctrl_conf_type peer_type;
+	struct rdt_parse_data data;
+	struct rdt_ctrl_domain *d;
+	char *dom = NULL, *id;
+	unsigned long dom_id;
+
+next:
+	if (!line || line[0] == '\0')
+		return 0;
+
+	dom = strsep(&line, ";");
+	id = strsep(&dom, "=");
+	if (!dom || kstrtoul(id, 10, &dom_id)) {
+		rdt_last_cmd_puts("Missing '=' or non-numeric domain\n");
+		return -EINVAL;
+	}
+
+	dom = strim(dom);

fs/resctrl/ctrlmondata.c +31 -0

+			 */
+			if (resctrl_arch_get_cdp_enabled(r->rid)) {
+				peer_type = resctrl_peer_type(s->conf_type);
+				memcpy(&d->staged_config[peer_type],
+				       &d->staged_config[s->conf_type],
+				       sizeof(d->staged_config[0]));
+			}
+			goto next;
+		}
+	}
+
+	return -EINVAL;
+}
+
+ssize_t resctrl_io_alloc_cbm_write(struct kernfs_open_file *of, char *buf,
+				   size_t nbytes, loff_t off)
+{
+	struct resctrl_schema *s = rdt_kn_parent_priv(of->kn);
+	struct rdt_resource *r = s->res;
+	u32 io_alloc_closid;
+	int ret = 0;
+
+	/* Valid input requires a trailing newline */
+	if (nbytes == 0 || buf[nbytes - 1] != '\n')
+		return -EINVAL;
+
+	buf[nbytes - 1] = '\0';
+
+	cpus_read_lock();
+	mutex_lock(&rdtgroup_mutex);
+	rdt_last_cmd_clear();

fs/resctrl/ctrlmondata.c +10 -0

+		goto out_unlock;
+	}
+
+	io_alloc_closid = resctrl_io_alloc_closid(r);
+
+	rdt_staged_configs_clear();
+	ret = resctrl_io_alloc_parse_line(buf, r, s, io_alloc_closid);
+	if (ret)
+		goto out_clear_configs;
+

Hi Babu,

Quoted 4 lines · Babu Moger

The io_alloc feature in resctrl enables system software to configure the portion of the cache allocated for I/O traffic. When supported, the io_alloc_cbm file in resctrl provides access to Capacity Bit Masks (CBMs) reserved for I/O devices.

reserved -> allocated?

The cache portions represented by CBMs are not reserved for I/O devices - these portions are available for sharing and can still be used by CPU cache allocation.

Quoted 2 lines

Enable users to modify io_alloc CBMs (Capacity Bit Masks) via the

Can drop "(Capacity Bit Masks)" since acronym was spelled out in first paragraph.

Quoted 4 lines

io_alloc_cbm resctrl file when io_alloc is enabled.

To ensure consistent cache allocation when CDP is enabled, the CBMs

This is not about "consistent cache allocation" but instead a consistent user interface. How about "To present consistent I/O allocation information to user space when CDP is enabled, the CBMs ..."

Quoted 2 lines

written to either L3CODE or L3DATA are mirrored to the other, keeping both resource types synchronized.

(needs imperative)

Quoted 4 lines

Signed-off-by Babu Moger <[email protected]>

---

...

Quoted 15 lines

---
  Documentation/filesystems/resctrl.rst | 11 ++++
  fs/resctrl/ctrlmondata.c              | 93 +++++++++++++++++++++++++++
  fs/resctrl/internal.h                 |  3 +
  fs/resctrl/rdtgroup.c                 |  3 +-
  4 files changed, 109 insertions(+), 1 deletion(-)

Documentation/filesystems/resctrl.rst +0 -0

index 15e3a4abf90e..7e3eda324de5 100644
@@ -188,6 +188,17 @@ related to allocation:
  			# cat /sys/fs/resctrl/info/L3/io_alloc_cbm
  			0=ffff;1=ffff
 

Documentation/filesystems/resctrl.rst related to allocation: · line 198

Quoted 8 lines

Documentation/filesystems/resctrl.rst +8 -0

+		CBMs can be configured by writing to the interface.
+
+		Example::
+
+			# echo 1=ff > /sys/fs/resctrl/info/L3/io_alloc_cbm
+			# cat /sys/fs/resctrl/info/L3/io_alloc_cbm
+			0=ffff;1=00ff
+			# echo 0=ff;1=f > /sys/fs/resctrl/info/L3/io_alloc_cbm

To accommodate how a shell may interpret above this should perhaps be (see schemata examples):

			# echo "0=ff;1=f" > /sys/fs/resctrl/info/L3/io_alloc_cbm

Quoted 41 lines

Documentation/filesystems/resctrl.rst +3 -0

+			# cat /sys/fs/resctrl/info/L3/io_alloc_cbm
+			0=00ff;1=000f
+
  		When CDP is enabled "io_alloc_cbm" associated with the DATA and CODE
  		resources may reflect the same values. For example, values read from and
  		written to /sys/fs/resctrl/info/L3DATA/io_alloc_cbm may be reflected by

fs/resctrl/ctrlmondata.c +27 -0

index a4e861733a95..791ecb559b50 100644
@@ -848,3 +848,96 @@ int resctrl_io_alloc_cbm_show(struct kernfs_open_file *of, struct seq_file *seq,
  	cpus_read_unlock();
  	return ret;
  }
+
+static int resctrl_io_alloc_parse_line(char *line,  struct rdt_resource *r,
+				       struct resctrl_schema *s, u32 closid)
+{
+	enum resctrl_conf_type peer_type;
+	struct rdt_parse_data data;
+	struct rdt_ctrl_domain *d;
+	char *dom = NULL, *id;
+	unsigned long dom_id;
+
+next:
+	if (!line || line[0] == '\0')
+		return 0;
+
+	dom = strsep(&line, ";");
+	id = strsep(&dom, "=");
+	if (!dom || kstrtoul(id, 10, &dom_id)) {
+		rdt_last_cmd_puts("Missing '=' or non-numeric domain\n");
+		return -EINVAL;
+	}
+
+	dom = strim(dom);
+	list_for_each_entry(d, &r->ctrl_domains, hdr.list) {
+		if (d->hdr.id == dom_id) {
+			data.buf = dom;
+			data.mode = RDT_MODE_SHAREABLE;
+			data.closid = closid;

fs/resctrl/ctrlmondata.c int resctrl_io_alloc_cbm_show(struct kernfs_open_file *of, struct seq_file *seq, · line 882

Quoted 5 lines

fs/resctrl/ctrlmondata.c +5 -0

+			if (parse_cbm(&data, s, d))
+				return -EINVAL;
+			/*
+			 * When CDP is enabled, update the schema for both CDP_DATA
+			 * and CDP_CODE.

The comment just describes what can be seen from the code. How about something like "Keep io_alloc CLOSID's CBM of CDP_CODE and CDP_DATA in sync."?

Of note is that these comments are generic while earlier comments related to CDP are L3 specific ("L3CODE" and "L3DATA"). Having resource specific names in generic code is not ideal, even if first implementation is only for L3. I think this was done in many places though, even in a couple of the changelogs I created and I now realize the impact after seeing this comment. Could you please take a look to make the name generic when it is used in generic changelog and comments?

Quoted 37 lines

fs/resctrl/ctrlmondata.c +36 -0

+			 */
+			if (resctrl_arch_get_cdp_enabled(r->rid)) {
+				peer_type = resctrl_peer_type(s->conf_type);
+				memcpy(&d->staged_config[peer_type],
+				       &d->staged_config[s->conf_type],
+				       sizeof(d->staged_config[0]));
+			}
+			goto next;
+		}
+	}
+
+	return -EINVAL;
+}
+
+ssize_t resctrl_io_alloc_cbm_write(struct kernfs_open_file *of, char *buf,
+				   size_t nbytes, loff_t off)
+{
+	struct resctrl_schema *s = rdt_kn_parent_priv(of->kn);
+	struct rdt_resource *r = s->res;
+	u32 io_alloc_closid;
+	int ret = 0;
+
+	/* Valid input requires a trailing newline */
+	if (nbytes == 0 || buf[nbytes - 1] != '\n')
+		return -EINVAL;
+
+	buf[nbytes - 1] = '\0';
+
+	cpus_read_lock();
+	mutex_lock(&rdtgroup_mutex);
+	rdt_last_cmd_clear();
+
+	if (!r->cache.io_alloc_capable) {
+		rdt_last_cmd_printf("io_alloc is not supported on %s\n", s->name);
+		ret = -ENODEV;
+		goto out_unlock;

fs/resctrl/ctrlmondata.c int resctrl_io_alloc_cbm_show(struct kernfs_open_file *of, struct seq_file *seq, · line 923

Quoted 5 lines

fs/resctrl/ctrlmondata.c +5 -0

+	}
+
+	if (!resctrl_arch_get_io_alloc_enabled(r)) {
+		rdt_last_cmd_printf("io_alloc is not enabled on %s\n", s->name);
+		ret = -ENODEV;

Compare to comment in patch #7 where the same error of io_alloc not being enabled results in different error code (EINVAL). Please keep these consistent.

Here is the updated full changelog.

fs/resctrl: Introduce interface to modify io_alloc Capacity Bit Masks

The io_alloc feature in resctrl enables system software to configure the
portion of the cache allocated for I/O traffic. When supported, the
io_alloc_cbm file in resctrl provides access to Capacity Bit Masks (CBMs) allocated for I/O devices.

Enable users to modify io_alloc CBMs via io_alloc_cbm resctrl file when the feature is enabled.

Mirror the CBMs between CDP_CODE and CDP_DATA when CDP is enabled to present consistent I/O allocation information to user space and keep both resource types synchronized.

Hi Babu,

On 9/19/25 1:49 PM, Moger, Babu wrote:

Quoted 3 lines

Here is the updated full changelog.

fs/resctrl: Introduce interface to modify io_alloc Capacity Bit Masks

I do not think it is necessary to use upper case if not following it by the acronym. I also think "bitmask" is usually one word? So:
fs/resctrl: Introduce interface to modify io_alloc capacity bitmasks

Quoted 5 lines

The io_alloc feature in resctrl enables system software to configure the
portion of the cache allocated for I/O traffic. When supported, the
io_alloc_cbm file in resctrl provides access to Capacity Bit Masks (CBMs) allocated for I/O devices.

Quoted 1 line

Enable users to modify io_alloc CBMs via io_alloc_cbm resctrl file when the feature is enabled.

(nit) can be made more specific with:

Enable users to modify io_alloc CBMs by writing to the io_alloc_cbm resctrl file when the io_alloc feature is enabled.

Quoted 2 lines

Mirror the CBMs between CDP_CODE and CDP_DATA when CDP is enabled to present consistent I/O allocation information to user space and keep both resource types synchronized.

I think "and keep both resource types synchronized" is redundant considering the sentence starts with "Mirror the CBMs"?

When the io_alloc feature is enabled, a portion of the cache can be configured for shared use between hardware and software.

Update bit_usage representation to reflect the io_alloc configuration. Revise the documentation for "shareable_bits" and "bit_usage" to reflect the impact of io_alloc feature.

Signed-off-by Babu Moger <[email protected]>

---

---
 Documentation/filesystems/resctrl.rst | 35 ++++++++++++++++-----------
 fs/resctrl/ctrlmondata.c              |  2 +-
 fs/resctrl/internal.h                 |  2 ++
 fs/resctrl/rdtgroup.c                 | 21 ++++++++++++++--
 4 files changed, 43 insertions(+), 17 deletions(-)

Documentation/filesystems/resctrl.rst +2 -6

index 7e3eda324de5..72ea6f3f36bc 100644
@@ -90,12 +90,19 @@ related to allocation:
 		must be set when writing a mask.
 
 "shareable_bits":
-		Bitmask of shareable resource with other executing
-		entities (e.g. I/O). User can use this when
-		setting up exclusive cache partitions. Note that
-		some platforms support devices that have their
-		own settings for cache use which can over-ride
-		these bits.
+		Bitmask of shareable resource with other executing entities
+		(e.g. I/O). Applies to all instances of this resource. User

Documentation/filesystems/resctrl.rst +1 -0

+
 "bit_usage":
 		Annotated capacity bitmasks showing how all
 		instances of the resource are used. The legend is:

@@ -109,16 +116,16 @@ related to allocation:
 			"H":

Hi Babu,

Quoted 2 lines · Babu Moger

When the io_alloc feature is enabled, a portion of the cache can be configured for shared use between hardware and software.

(repetitive)

Quoted 4 lines

Update bit_usage representation to reflect the io_alloc configuration. Revise the documentation for "shareable_bits" and "bit_usage" to reflect the impact of io_alloc feature.

Attempt at new version, please feel free to improve:

The "shareable_bits" and "bit_usage" resctrl files associated with cache resources give insight into how instances of a cache is used.

Update the annotated capacity bitmasks displayed by "bit_usage" to include the cache portions allocated for I/O via the "io_alloc" feature. "shareable_bits" is a global bitmask of shareable cache with I/O and can thus not present the per-domain I/O allocations possible with the "io_alloc" feature. Revise the "shareable_bits" documentation to direct users to "bit_usage" for accurate cache usage information.

Quoted 3 lines

Signed-off-by Babu Moger <[email protected]>

---

...

Quoted 27 lines

---
  Documentation/filesystems/resctrl.rst | 35 ++++++++++++++++-----------
  fs/resctrl/ctrlmondata.c              |  2 +-
  fs/resctrl/internal.h                 |  2 ++
  fs/resctrl/rdtgroup.c                 | 21 ++++++++++++++--
  4 files changed, 43 insertions(+), 17 deletions(-)

Documentation/filesystems/resctrl.rst +6 -6

index 7e3eda324de5..72ea6f3f36bc 100644
@@ -90,12 +90,19 @@ related to allocation:
  		must be set when writing a mask.
 
  "shareable_bits":
-		Bitmask of shareable resource with other executing
-		entities (e.g. I/O). User can use this when
-		setting up exclusive cache partitions. Note that
-		some platforms support devices that have their
-		own settings for cache use which can over-ride
-		these bits.
+		Bitmask of shareable resource with other executing entities
+		(e.g. I/O). Applies to all instances of this resource. User
+		can use this when setting up exclusive cache partitions.
+		Note that some platforms support devices that have their
+		own settings for cache use which can over-ride these bits.
+

Documentation/filesystems/resctrl.rst related to allocation: · line 104

Quoted 6 lines

Documentation/filesystems/resctrl.rst +6 -0

+		When "io_alloc" is enabled, a portion of each cache instance can
+		be configured for shared use between hardware and software.
+		"bit_usage" should be used to see which portions of each cache
+		instance is configured for hardware use via "io_alloc" feature
+		because every cache instance can have its "io_alloc" bitmask
+		configured independently via io_alloc_cbm.

io_alloc_cbm -> "io_alloc_cbm" (to consistently place names of resctrl files in quotes)

Quoted 12 lines

Documentation/filesystems/resctrl.rst +1 -3

+
  "bit_usage":
  		Annotated capacity bitmasks showing how all
  		instances of the resource are used. The legend is:

@@ -109,16 +116,16 @@ related to allocation:
  			"H":
  			      Corresponding region is used by hardware only
  			      but available for software use. If a resource
-			      has bits set in "shareable_bits" but not all
-			      of these bits appear in the resource groups'
-			      schematas then the bits appearing in

Documentation/filesystems/resctrl.rst related to allocation: · line 121

Quoted 5 lines

Documentation/filesystems/resctrl.rst +3 -2

-			      "shareable_bits" but no resource group will
-			      be marked as "H".
+			      has bits set in "shareable_bits" or "io_alloc_cbm"
+			      but not all of these bits appear in the resource
+			      groups' schematas then the bits appearing in

I understand that you are just copying this but "schemata" is plural of "schema". Since you are copying this text, could you please fix "schematas" to be "schemata" while doing so?