* [PATCH v8 01/10] x86/cpufeatures: Add support for L3 Smart Data Cache Injection Allocation Enforcement
2025-08-05 23:30 [PATCH v8 00/10] x86,fs/resctrl: Support L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE) Babu Moger
@ 2025-08-05 23:30 ` Babu Moger
2025-08-05 23:30 ` [PATCH v8 02/10] x86/resctrl: Add SDCIAE feature in the command line options Babu Moger
` (8 subsequent siblings)
9 siblings, 0 replies; 34+ messages in thread
From: Babu Moger @ 2025-08-05 23:30 UTC (permalink / raw)
To: corbet, tony.luck, reinette.chatre, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, babu.moger,
yosry.ahmed, sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
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 feature details are documented in APM listed below [1].
[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
Signed-off-by: Babu Moger <babu.moger@amd.com>
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
---
v8: Added Acked-by, Reviewed-by tags.
v7: No changes. Fixed few conflicts in
arch/x86/include/asm/cpufeatures.h
arch/x86/kernel/cpu/scattered.c
v6: Resolved conflicts in cpufeatures.h.
v5: No changes.
v4: Resolved a minor conflict in cpufeatures.h.
v3: No changes.
v2: Added dependancy on X86_FEATURE_CAT_L3
Removed the "" in CPU feature definition.
Minor text changes.
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/kernel/cpu/cpuid-deps.c | 1 +
arch/x86/kernel/cpu/scattered.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 602957dd2609..db020bd60edc 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -494,6 +494,7 @@
#define X86_FEATURE_TSA_SQ_NO (21*32+11) /* AMD CPU not vulnerable to TSA-SQ */
#define X86_FEATURE_TSA_L1_NO (21*32+12) /* AMD CPU not vulnerable to TSA-L1 */
#define X86_FEATURE_CLEAR_CPU_BUF_VM (21*32+13) /* Clear CPU buffers using VERW before VMRUN */
+#define X86_FEATURE_SDCIAE (21*32+14) /* L3 Smart Data Cache Injection Allocation Enforcement */
/*
* BUG word(s)
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index 46efcbd6afa4..87e78586395b 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -72,6 +72,7 @@ static const struct cpuid_dep cpuid_deps[] = {
{ X86_FEATURE_CQM_MBM_LOCAL, X86_FEATURE_CQM_LLC },
{ X86_FEATURE_BMEC, X86_FEATURE_CQM_MBM_TOTAL },
{ X86_FEATURE_BMEC, X86_FEATURE_CQM_MBM_LOCAL },
+ { X86_FEATURE_SDCIAE, X86_FEATURE_CAT_L3 },
{ X86_FEATURE_AVX512_BF16, X86_FEATURE_AVX512VL },
{ X86_FEATURE_AVX512_FP16, X86_FEATURE_AVX512BW },
{ X86_FEATURE_ENQCMD, X86_FEATURE_XSAVES },
diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
index b4a1f6732a3a..b22bfe81d262 100644
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -50,6 +50,7 @@ static const struct cpuid_bit cpuid_bits[] = {
{ X86_FEATURE_MBA, CPUID_EBX, 6, 0x80000008, 0 },
{ X86_FEATURE_SMBA, CPUID_EBX, 2, 0x80000020, 0 },
{ X86_FEATURE_BMEC, CPUID_EBX, 3, 0x80000020, 0 },
+ { X86_FEATURE_SDCIAE, CPUID_EBX, 6, 0x80000020, 0 },
{ X86_FEATURE_TSA_SQ_NO, CPUID_ECX, 1, 0x80000021, 0 },
{ X86_FEATURE_TSA_L1_NO, CPUID_ECX, 2, 0x80000021, 0 },
{ X86_FEATURE_AMD_WORKLOAD_CLASS, CPUID_EAX, 22, 0x80000021, 0 },
--
2.34.1
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v8 02/10] x86/resctrl: Add SDCIAE feature in the command line options
2025-08-05 23:30 [PATCH v8 00/10] x86,fs/resctrl: Support L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE) Babu Moger
2025-08-05 23:30 ` [PATCH v8 01/10] x86/cpufeatures: Add support for L3 Smart Data Cache Injection Allocation Enforcement Babu Moger
@ 2025-08-05 23:30 ` Babu Moger
2025-08-08 1:44 ` Reinette Chatre
2025-08-05 23:30 ` [PATCH v8 03/10] x86,fs/resctrl: Detect io_alloc feature Babu Moger
` (7 subsequent siblings)
9 siblings, 1 reply; 34+ messages in thread
From: Babu Moger @ 2025-08-05 23:30 UTC (permalink / raw)
To: corbet, tony.luck, reinette.chatre, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, babu.moger,
yosry.ahmed, sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Add the command line options to enable or disable the new resctrl feature
L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE).
Signed-off-by: Babu Moger <babu.moger@amd.com>
---
v8: Updated Documentation/filesystems/resctrl.rst.
v7: No changes.
v6: No changes.
v5: No changes.
v4: No changes.
v3: No changes.
v2: No changes.
---
.../admin-guide/kernel-parameters.txt | 2 +-
Documentation/filesystems/resctrl.rst | 21 ++++++++++---------
arch/x86/kernel/cpu/resctrl/core.c | 2 ++
3 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 0d2ea9a60145..0170c0af03cc 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -6089,7 +6089,7 @@
rdt= [HW,X86,RDT]
Turn on/off individual RDT features. List is:
cmt, mbmtotal, mbmlocal, l3cat, l3cdp, l2cat, l2cdp,
- mba, smba, bmec.
+ mba, smba, bmec, sdciae.
E.g. to turn on cmt and turn off mba use:
rdt=cmt,!mba
diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
index c7949dd44f2f..f08699030312 100644
--- a/Documentation/filesystems/resctrl.rst
+++ b/Documentation/filesystems/resctrl.rst
@@ -17,16 +17,17 @@ AMD refers to this feature as AMD Platform Quality of Service(AMD QoS).
This feature is enabled by the CONFIG_X86_CPU_RESCTRL and the x86 /proc/cpuinfo
flag bits:
-=============================================== ================================
-RDT (Resource Director Technology) Allocation "rdt_a"
-CAT (Cache Allocation Technology) "cat_l3", "cat_l2"
-CDP (Code and Data Prioritization) "cdp_l3", "cdp_l2"
-CQM (Cache QoS Monitoring) "cqm_llc", "cqm_occup_llc"
-MBM (Memory Bandwidth Monitoring) "cqm_mbm_total", "cqm_mbm_local"
-MBA (Memory Bandwidth Allocation) "mba"
-SMBA (Slow Memory Bandwidth Allocation) ""
-BMEC (Bandwidth Monitoring Event Configuration) ""
-=============================================== ================================
+=============================================================== ================================
+RDT (Resource Director Technology) Allocation "rdt_a"
+CAT (Cache Allocation Technology) "cat_l3", "cat_l2"
+CDP (Code and Data Prioritization) "cdp_l3", "cdp_l2"
+CQM (Cache QoS Monitoring) "cqm_llc", "cqm_occup_llc"
+MBM (Memory Bandwidth Monitoring) "cqm_mbm_total", "cqm_mbm_local"
+MBA (Memory Bandwidth Allocation) "mba"
+SMBA (Slow Memory Bandwidth Allocation) ""
+BMEC (Bandwidth Monitoring Event Configuration) ""
+SDCIAE (Smart Data Cache Injection Allocation Enforcement) ""
+=============================================================== ================================
Historically, new features were made visible by default in /proc/cpuinfo. This
resulted in the feature flags becoming hard to parse by humans. Adding a new
diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
index 187d527ef73b..f6d84882cc4e 100644
--- a/arch/x86/kernel/cpu/resctrl/core.c
+++ b/arch/x86/kernel/cpu/resctrl/core.c
@@ -707,6 +707,7 @@ enum {
RDT_FLAG_MBA,
RDT_FLAG_SMBA,
RDT_FLAG_BMEC,
+ RDT_FLAG_SDCIAE,
};
#define RDT_OPT(idx, n, f) \
@@ -732,6 +733,7 @@ static struct rdt_options rdt_options[] __ro_after_init = {
RDT_OPT(RDT_FLAG_MBA, "mba", X86_FEATURE_MBA),
RDT_OPT(RDT_FLAG_SMBA, "smba", X86_FEATURE_SMBA),
RDT_OPT(RDT_FLAG_BMEC, "bmec", X86_FEATURE_BMEC),
+ RDT_OPT(RDT_FLAG_SDCIAE, "sdciae", X86_FEATURE_SDCIAE),
};
#define NUM_RDT_OPTIONS ARRAY_SIZE(rdt_options)
--
2.34.1
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH v8 02/10] x86/resctrl: Add SDCIAE feature in the command line options
2025-08-05 23:30 ` [PATCH v8 02/10] x86/resctrl: Add SDCIAE feature in the command line options Babu Moger
@ 2025-08-08 1:44 ` Reinette Chatre
2025-08-22 22:07 ` Moger, Babu
0 siblings, 1 reply; 34+ messages in thread
From: Reinette Chatre @ 2025-08-08 1:44 UTC (permalink / raw)
To: Babu Moger, corbet, tony.luck, Dave.Martin, james.morse, tglx,
mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Babu,
On 8/5/25 4:30 PM, Babu Moger wrote:
> Add the command line options to enable or disable the new resctrl feature
options -> option?
> L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE).
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> ---
> ---
> .../admin-guide/kernel-parameters.txt | 2 +-
> Documentation/filesystems/resctrl.rst | 21 ++++++++++---------
> arch/x86/kernel/cpu/resctrl/core.c | 2 ++
> 3 files changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 0d2ea9a60145..0170c0af03cc 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -6089,7 +6089,7 @@
> rdt= [HW,X86,RDT]
> Turn on/off individual RDT features. List is:
> cmt, mbmtotal, mbmlocal, l3cat, l3cdp, l2cat, l2cdp,
> - mba, smba, bmec.
> + mba, smba, bmec, sdciae.
> E.g. to turn on cmt and turn off mba use:
> rdt=cmt,!mba
>
> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
> index c7949dd44f2f..f08699030312 100644
> --- a/Documentation/filesystems/resctrl.rst
> +++ b/Documentation/filesystems/resctrl.rst
> @@ -17,16 +17,17 @@ AMD refers to this feature as AMD Platform Quality of Service(AMD QoS).
> This feature is enabled by the CONFIG_X86_CPU_RESCTRL and the x86 /proc/cpuinfo
> flag bits:
>
> -=============================================== ================================
> -RDT (Resource Director Technology) Allocation "rdt_a"
> -CAT (Cache Allocation Technology) "cat_l3", "cat_l2"
> -CDP (Code and Data Prioritization) "cdp_l3", "cdp_l2"
> -CQM (Cache QoS Monitoring) "cqm_llc", "cqm_occup_llc"
> -MBM (Memory Bandwidth Monitoring) "cqm_mbm_total", "cqm_mbm_local"
> -MBA (Memory Bandwidth Allocation) "mba"
> -SMBA (Slow Memory Bandwidth Allocation) ""
> -BMEC (Bandwidth Monitoring Event Configuration) ""
> -=============================================== ================================
> +=============================================================== ================================
> +RDT (Resource Director Technology) Allocation "rdt_a"
> +CAT (Cache Allocation Technology) "cat_l3", "cat_l2"
> +CDP (Code and Data Prioritization) "cdp_l3", "cdp_l2"
> +CQM (Cache QoS Monitoring) "cqm_llc", "cqm_occup_llc"
> +MBM (Memory Bandwidth Monitoring) "cqm_mbm_total", "cqm_mbm_local"
> +MBA (Memory Bandwidth Allocation) "mba"
> +SMBA (Slow Memory Bandwidth Allocation) ""
With all these adjustments this looks like an ideal time to fix the missing TABs in the SMBA spacing?
> +BMEC (Bandwidth Monitoring Event Configuration) ""
> +SDCIAE (Smart Data Cache Injection Allocation Enforcement) ""
> +=============================================================== ================================
Reinette
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v8 02/10] x86/resctrl: Add SDCIAE feature in the command line options
2025-08-08 1:44 ` Reinette Chatre
@ 2025-08-22 22:07 ` Moger, Babu
0 siblings, 0 replies; 34+ messages in thread
From: Moger, Babu @ 2025-08-22 22:07 UTC (permalink / raw)
To: Reinette Chatre, corbet, tony.luck, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Reinette,
Thanks for the comments. It took a while to get to it.
On 8/7/2025 8:44 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 8/5/25 4:30 PM, Babu Moger wrote:
>> Add the command line options to enable or disable the new resctrl feature
> options -> option?
sure.
>
>> L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE).
>>
>> Signed-off-by: Babu Moger <babu.moger@amd.com>
>> ---
>> ---
>> .../admin-guide/kernel-parameters.txt | 2 +-
>> Documentation/filesystems/resctrl.rst | 21 ++++++++++---------
>> arch/x86/kernel/cpu/resctrl/core.c | 2 ++
>> 3 files changed, 14 insertions(+), 11 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 0d2ea9a60145..0170c0af03cc 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -6089,7 +6089,7 @@
>> rdt= [HW,X86,RDT]
>> Turn on/off individual RDT features. List is:
>> cmt, mbmtotal, mbmlocal, l3cat, l3cdp, l2cat, l2cdp,
>> - mba, smba, bmec.
>> + mba, smba, bmec, sdciae.
>> E.g. to turn on cmt and turn off mba use:
>> rdt=cmt,!mba
>>
>> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
>> index c7949dd44f2f..f08699030312 100644
>> --- a/Documentation/filesystems/resctrl.rst
>> +++ b/Documentation/filesystems/resctrl.rst
>> @@ -17,16 +17,17 @@ AMD refers to this feature as AMD Platform Quality of Service(AMD QoS).
>> This feature is enabled by the CONFIG_X86_CPU_RESCTRL and the x86 /proc/cpuinfo
>> flag bits:
>>
>> -=============================================== ================================
>> -RDT (Resource Director Technology) Allocation "rdt_a"
>> -CAT (Cache Allocation Technology) "cat_l3", "cat_l2"
>> -CDP (Code and Data Prioritization) "cdp_l3", "cdp_l2"
>> -CQM (Cache QoS Monitoring) "cqm_llc", "cqm_occup_llc"
>> -MBM (Memory Bandwidth Monitoring) "cqm_mbm_total", "cqm_mbm_local"
>> -MBA (Memory Bandwidth Allocation) "mba"
>> -SMBA (Slow Memory Bandwidth Allocation) ""
>> -BMEC (Bandwidth Monitoring Event Configuration) ""
>> -=============================================== ================================
>> +=============================================================== ================================
>> +RDT (Resource Director Technology) Allocation "rdt_a"
>> +CAT (Cache Allocation Technology) "cat_l3", "cat_l2"
>> +CDP (Code and Data Prioritization) "cdp_l3", "cdp_l2"
>> +CQM (Cache QoS Monitoring) "cqm_llc", "cqm_occup_llc"
>> +MBM (Memory Bandwidth Monitoring) "cqm_mbm_total", "cqm_mbm_local"
>> +MBA (Memory Bandwidth Allocation) "mba"
>> +SMBA (Slow Memory Bandwidth Allocation) ""
> With all these adjustments this looks like an ideal time to fix the missing TABs in the SMBA spacing?
Sure. Noticed both SMBA and BMEC had tabs missing. Taken care now.
thanks
Babu
>
>> +BMEC (Bandwidth Monitoring Event Configuration) ""
>> +SDCIAE (Smart Data Cache Injection Allocation Enforcement) ""
>> +=============================================================== ================================
> Reinette
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v8 03/10] x86,fs/resctrl: Detect io_alloc feature
2025-08-05 23:30 [PATCH v8 00/10] x86,fs/resctrl: Support L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE) Babu Moger
2025-08-05 23:30 ` [PATCH v8 01/10] x86/cpufeatures: Add support for L3 Smart Data Cache Injection Allocation Enforcement Babu Moger
2025-08-05 23:30 ` [PATCH v8 02/10] x86/resctrl: Add SDCIAE feature in the command line options Babu Moger
@ 2025-08-05 23:30 ` Babu Moger
2025-08-05 23:30 ` [PATCH v8 04/10] x86,fs/resctrl: Implement "io_alloc" enable/disable handlers Babu Moger
` (6 subsequent siblings)
9 siblings, 0 replies; 34+ messages in thread
From: Babu Moger @ 2025-08-05 23:30 UTC (permalink / raw)
To: corbet, tony.luck, reinette.chatre, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, babu.moger,
yosry.ahmed, sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
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 <babu.moger@amd.com>
Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
---
v8: Added Reviewed-by tag.
v7: Few text updates in changelog and resctrl.h.
v6: No changes.
v5: No changes.
v4: Updated the commit message and code comment based on feedback.
v3: Rewrote commit log. Changed the text to bit generic than the AMD specific.
Renamed the rdt_get_sdciae_alloc_cfg() to rdt_set_io_alloc_capable().
Removed leftover comment from v2.
v2: Changed sdciae_capable to io_alloc_capable to make it generic feature.
Also moved the io_alloc_capable in struct resctrl_cache.
---
arch/x86/kernel/cpu/resctrl/core.c | 7 +++++++
include/linux/resctrl.h | 3 +++
2 files changed, 10 insertions(+)
diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
index f6d84882cc4e..1d1002526745 100644
--- a/arch/x86/kernel/cpu/resctrl/core.c
+++ b/arch/x86/kernel/cpu/resctrl/core.c
@@ -274,6 +274,11 @@ static void rdt_get_cdp_config(int level)
rdt_resources_all[level].r_resctrl.cdp_capable = true;
}
+static void rdt_set_io_alloc_capable(struct rdt_resource *r)
+{
+ r->cache.io_alloc_capable = true;
+}
+
static void rdt_get_cdp_l3_config(void)
{
rdt_get_cdp_config(RDT_RESOURCE_L3);
@@ -842,6 +847,8 @@ static __init bool get_rdt_alloc_resources(void)
rdt_get_cache_alloc_cfg(1, r);
if (rdt_cpu_has(X86_FEATURE_CDP_L3))
rdt_get_cdp_l3_config();
+ if (rdt_cpu_has(X86_FEATURE_SDCIAE))
+ rdt_set_io_alloc_capable(r);
ret = true;
}
if (rdt_cpu_has(X86_FEATURE_CAT_L2)) {
diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
index 6fb4894b8cfd..010f238843b2 100644
--- a/include/linux/resctrl.h
+++ b/include/linux/resctrl.h
@@ -191,6 +191,8 @@ struct rdt_mon_domain {
* @arch_has_sparse_bitmasks: True if a bitmask like f00f is valid.
* @arch_has_per_cpu_cfg: True if QOS_CFG register for this cache
* level has CPU scope.
+ * @io_alloc_capable: True if portion of the cache can be configured
+ * for I/O traffic.
*/
struct resctrl_cache {
unsigned int cbm_len;
@@ -198,6 +200,7 @@ struct resctrl_cache {
unsigned int shareable_bits;
bool arch_has_sparse_bitmasks;
bool arch_has_per_cpu_cfg;
+ bool io_alloc_capable;
};
/**
--
2.34.1
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v8 04/10] x86,fs/resctrl: Implement "io_alloc" enable/disable handlers
2025-08-05 23:30 [PATCH v8 00/10] x86,fs/resctrl: Support L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE) Babu Moger
` (2 preceding siblings ...)
2025-08-05 23:30 ` [PATCH v8 03/10] x86,fs/resctrl: Detect io_alloc feature Babu Moger
@ 2025-08-05 23:30 ` Babu Moger
2025-08-08 1:47 ` Reinette Chatre
2025-08-05 23:30 ` [PATCH v8 05/10] fs/resctrl: Introduce interface to display "io_alloc" support Babu Moger
` (5 subsequent siblings)
9 siblings, 1 reply; 34+ messages in thread
From: Babu Moger @ 2025-08-05 23:30 UTC (permalink / raw)
To: corbet, tony.luck, reinette.chatre, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, babu.moger,
yosry.ahmed, sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
"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 available in APM listed below [1].
[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
Signed-off-by: Babu Moger <babu.moger@amd.com>
---
v8: Moved resctrl_arch_io_alloc_enable() and its dependancies to
arch/x86/kernel/cpu/resctrl/ctrlmondata.c file.
v7: Removed the inline for resctrl_arch_get_io_alloc_enabled().
Update code comment in resctrl.h.
Changed the subject to x86,fs/resctrl.
v6: Added lockdep_assert_cpus_held() in _resctrl_sdciae_enable() to protect
r->ctrl_domains.
Added more comments in include/linux/resctrl.h.
v5: Resolved conflicts due to recent resctrl FS/ARCH code restructure.
The files monitor.c/rdtgroup.c have been split between FS and ARCH directories.
Moved prototypes of resctrl_arch_io_alloc_enable() and
resctrl_arch_get_io_alloc_enabled() to include/linux/resctrl.h.
v4: Updated the commit log to address the feedback.
v3: Passed the struct rdt_resource to resctrl_arch_get_io_alloc_enabled() instead of resource id.
Renamed the _resctrl_io_alloc_enable() to _resctrl_sdciae_enable() as it is arch specific.
Changed the return to void in _resctrl_sdciae_enable() instead of int.
Added more context in commit log and fixed few typos.
v2: Renamed the functions to simplify the code.
Renamed sdciae_capable to io_alloc_capable.
Changed the name of few arch functions similar to ABMC series.
resctrl_arch_get_io_alloc_enabled()
resctrl_arch_io_alloc_enable()
---
arch/x86/include/asm/msr-index.h | 1 +
arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 40 +++++++++++++++++++++++
arch/x86/kernel/cpu/resctrl/internal.h | 5 +++
include/linux/resctrl.h | 21 ++++++++++++
4 files changed, 67 insertions(+)
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 7490bb5c0776..c998cf0e1375 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -1222,6 +1222,7 @@
/* - AMD: */
#define MSR_IA32_MBA_BW_BASE 0xc0000200
#define MSR_IA32_SMBA_BW_BASE 0xc0000280
+#define MSR_IA32_L3_QOS_EXT_CFG 0xc00003ff
#define MSR_IA32_EVT_CFG_BASE 0xc0000400
/* AMD-V MSRs */
diff --git a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
index 1189c0df4ad7..85b6bd6bfb81 100644
--- a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
+++ b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
@@ -91,3 +91,43 @@ u32 resctrl_arch_get_config(struct rdt_resource *r, struct rdt_ctrl_domain *d,
return hw_dom->ctrl_val[idx];
}
+
+bool resctrl_arch_get_io_alloc_enabled(struct rdt_resource *r)
+{
+ return resctrl_to_arch_res(r)->sdciae_enabled;
+}
+
+static void resctrl_sdciae_set_one_amd(void *arg)
+{
+ bool *enable = arg;
+
+ if (*enable)
+ msr_set_bit(MSR_IA32_L3_QOS_EXT_CFG, SDCIAE_ENABLE_BIT);
+ else
+ msr_clear_bit(MSR_IA32_L3_QOS_EXT_CFG, SDCIAE_ENABLE_BIT);
+}
+
+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 */
+ 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;
+}
diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h
index 5e3c41b36437..70f5317f1ce4 100644
--- a/arch/x86/kernel/cpu/resctrl/internal.h
+++ b/arch/x86/kernel/cpu/resctrl/internal.h
@@ -37,6 +37,9 @@ struct arch_mbm_state {
u64 prev_msr;
};
+/* Setting bit 1 in L3_QOS_EXT_CFG enables the SDCIAE feature. */
+#define SDCIAE_ENABLE_BIT 1
+
/**
* struct rdt_hw_ctrl_domain - Arch private attributes of a set of CPUs that share
* a resource for a control function
@@ -102,6 +105,7 @@ struct msr_param {
* @mon_scale: cqm counter * mon_scale = occupancy in bytes
* @mbm_width: Monitor width, to detect and correct for overflow.
* @cdp_enabled: CDP state of this resource
+ * @sdciae_enabled: SDCIAE feature (backing "io_alloc") is enabled.
*
* Members of this structure are either private to the architecture
* e.g. mbm_width, or accessed via helpers that provide abstraction. e.g.
@@ -115,6 +119,7 @@ struct rdt_hw_resource {
unsigned int mon_scale;
unsigned int mbm_width;
bool cdp_enabled;
+ bool sdciae_enabled;
};
static inline struct rdt_hw_resource *resctrl_to_arch_res(struct rdt_resource *r)
diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
index 010f238843b2..d98933ce77af 100644
--- a/include/linux/resctrl.h
+++ b/include/linux/resctrl.h
@@ -531,6 +531,27 @@ void resctrl_arch_reset_rmid_all(struct rdt_resource *r, struct rdt_mon_domain *
*/
void resctrl_arch_reset_all_ctrls(struct rdt_resource *r);
+/**
+ * resctrl_arch_io_alloc_enable() - Enable/disable io_alloc feature.
+ * @r: The resctrl resource.
+ * @enable: Enable (true) or disable (false) io_alloc on resource @r.
+ *
+ * This can be called from any CPU.
+ *
+ * Return:
+ * 0 on success, <0 on error.
+ */
+int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable);
+
+/**
+ * resctrl_arch_get_io_alloc_enabled() - Get io_alloc feature state.
+ * @r: The resctrl resource.
+ *
+ * Return:
+ * true if io_alloc is enabled or false if disabled.
+ */
+bool resctrl_arch_get_io_alloc_enabled(struct rdt_resource *r);
+
extern unsigned int resctrl_rmid_realloc_threshold;
extern unsigned int resctrl_rmid_realloc_limit;
--
2.34.1
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH v8 04/10] x86,fs/resctrl: Implement "io_alloc" enable/disable handlers
2025-08-05 23:30 ` [PATCH v8 04/10] x86,fs/resctrl: Implement "io_alloc" enable/disable handlers Babu Moger
@ 2025-08-08 1:47 ` Reinette Chatre
2025-08-22 22:10 ` Moger, Babu
0 siblings, 1 reply; 34+ messages in thread
From: Reinette Chatre @ 2025-08-08 1:47 UTC (permalink / raw)
To: Babu Moger, corbet, tony.luck, Dave.Martin, james.morse, tglx,
mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Babu,
On 8/5/25 4:30 PM, Babu Moger wrote:
> "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 available in APM listed below [1].
> [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
fyi ... Documentation/process/maintainer-tip.rst has some examples how
the "Link:" can be associated with the changelog. For example, above could
be:
The SDCIAE feature details are available in APM [1] available
from [2].
[1] ...
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 # [2]
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> ---
Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
Reinette
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v8 04/10] x86,fs/resctrl: Implement "io_alloc" enable/disable handlers
2025-08-08 1:47 ` Reinette Chatre
@ 2025-08-22 22:10 ` Moger, Babu
0 siblings, 0 replies; 34+ messages in thread
From: Moger, Babu @ 2025-08-22 22:10 UTC (permalink / raw)
To: Reinette Chatre, corbet, tony.luck, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Reinette,
On 8/7/2025 8:47 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 8/5/25 4:30 PM, Babu Moger wrote:
>> "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 available in APM listed below [1].
>> [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
> fyi ... Documentation/process/maintainer-tip.rst has some examples how
> the "Link:" can be associated with the changelog. For example, above could
> be:
>
> The SDCIAE feature details are available in APM [1] available
> from [2].
> [1] ...
Sure.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 # [2]
>
>> Signed-off-by: Babu Moger <babu.moger@amd.com>
>> ---
> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
>
Thanks
Babu
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v8 05/10] fs/resctrl: Introduce interface to display "io_alloc" support
2025-08-05 23:30 [PATCH v8 00/10] x86,fs/resctrl: Support L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE) Babu Moger
` (3 preceding siblings ...)
2025-08-05 23:30 ` [PATCH v8 04/10] x86,fs/resctrl: Implement "io_alloc" enable/disable handlers Babu Moger
@ 2025-08-05 23:30 ` Babu Moger
2025-08-08 1:48 ` Reinette Chatre
2025-08-05 23:30 ` [PATCH v8 06/10] fs/resctrl: Add user interface to enable/disable io_alloc feature Babu Moger
` (4 subsequent siblings)
9 siblings, 1 reply; 34+ messages in thread
From: Babu Moger @ 2025-08-05 23:30 UTC (permalink / raw)
To: corbet, tony.luck, reinette.chatre, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, babu.moger,
yosry.ahmed, sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
"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 <babu.moger@amd.com>
---
v8: Updated Documentation/filesystems/resctrl.rst.
Moved resctrl_io_alloc_show() to fs/resctrl/ctrlmondata.c.
Added prototype for rdt_kn_parent_priv() in fs/resctrl/internal.h
so, it can be uses in other fs/resctrl/ files.
Added comment for io_alloc_init().
v7: Updated the changelog.
Updated user doc for io_alloc in resctrl.rst.
Added mutex rdtgroup_mutex in resctrl_io_alloc_show();
v6: Added "io_alloc_cbm" details in user doc resctrl.rst.
Resource name is not printed in CBM now. Corrected the texts about it
in resctrl.rst.
v5: Resolved conflicts due to recent resctrl FS/ARCH code restructure.
Updated show_doms() to print the resource if only it is valid. Pass NULL while
printing io_alloc CBM.
Changed the code to access the CBMs via either L3CODE or L3DATA resources.
v4: Updated the change log.
Added rdtgroup_mutex before rdt_last_cmd_puts().
Returned -ENODEV when resource type is CDP_DATA.
Kept the resource name while printing the CBM (L3:0=fff) that way
I dont have to change show_doms() just for this feature and it is
consistant across all the schemata display.
v3: Minor changes due to changes in resctrl_arch_get_io_alloc_enabled()
and resctrl_io_alloc_closid_get().
Added the check to verify CDP resource type.
Updated the commit log.
v2: Fixed to display only on L3 resources.
Added the locks while processing.
Rename the displat to io_alloc_cbm (from sdciae_cmd).
---
Documentation/filesystems/resctrl.rst | 29 +++++++++++++++++++++++++++
fs/resctrl/ctrlmondata.c | 21 +++++++++++++++++++
fs/resctrl/internal.h | 5 +++++
fs/resctrl/rdtgroup.c | 24 +++++++++++++++++++++-
4 files changed, 78 insertions(+), 1 deletion(-)
diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
index f08699030312..fff7e04d1e2a 100644
--- a/Documentation/filesystems/resctrl.rst
+++ b/Documentation/filesystems/resctrl.rst
@@ -136,6 +136,35 @@ 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":
+ Portions of cache used for allocation of I/O traffic
+ cannot be configured.
+ "enabled":
+ 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.
+
+ 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, the 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
+ 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:
diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
index d98e0d2de09f..d495a5d5c9d5 100644
--- a/fs/resctrl/ctrlmondata.c
+++ b/fs/resctrl/ctrlmondata.c
@@ -664,3 +664,24 @@ int rdtgroup_mondata_show(struct seq_file *m, void *arg)
rdtgroup_kn_unlock(of->kn);
return ret;
}
+
+int resctrl_io_alloc_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;
+
+ mutex_lock(&rdtgroup_mutex);
+
+ if (r->cache.io_alloc_capable) {
+ if (resctrl_arch_get_io_alloc_enabled(r))
+ seq_puts(seq, "enabled\n");
+ else
+ seq_puts(seq, "disabled\n");
+ } else {
+ seq_puts(seq, "not supported\n");
+ }
+
+ mutex_unlock(&rdtgroup_mutex);
+
+ return 0;
+}
diff --git a/fs/resctrl/internal.h b/fs/resctrl/internal.h
index 0a1eedba2b03..1a4543c2b988 100644
--- a/fs/resctrl/internal.h
+++ b/fs/resctrl/internal.h
@@ -375,6 +375,11 @@ bool closid_allocated(unsigned int closid);
int resctrl_find_cleanest_closid(void);
+int resctrl_io_alloc_show(struct kernfs_open_file *of, struct seq_file *seq,
+ void *v);
+
+void *rdt_kn_parent_priv(struct kernfs_node *kn);
+
#ifdef CONFIG_RESCTRL_FS_PSEUDO_LOCK
int rdtgroup_locksetup_enter(struct rdtgroup *rdtgrp);
diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index 77d08229d855..acc9edc1a268 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -981,7 +981,7 @@ static int rdt_last_cmd_status_show(struct kernfs_open_file *of,
return 0;
}
-static void *rdt_kn_parent_priv(struct kernfs_node *kn)
+void *rdt_kn_parent_priv(struct kernfs_node *kn)
{
/*
* The parent pointer is only valid within RCU section since it can be
@@ -1893,6 +1893,12 @@ static struct rftype res_common_files[] = {
.kf_ops = &rdtgroup_kf_single_ops,
.seq_show = rdt_thread_throttle_mode_show,
},
+ {
+ .name = "io_alloc",
+ .mode = 0444,
+ .kf_ops = &rdtgroup_kf_single_ops,
+ .seq_show = resctrl_io_alloc_show,
+ },
{
.name = "max_threshold_occupancy",
.mode = 0644,
@@ -2062,6 +2068,20 @@ static void thread_throttle_mode_init(void)
RFTYPE_CTRL_INFO | RFTYPE_RES_MB);
}
+/*
+ * The resctrl file "io_alloc" is added using L3 resource. However, it results
+ * in this file being visible for *all* cache resources (eg. L2 cache),
+ * whether it supports "io_alloc" or not.
+ */
+static void io_alloc_init(void)
+{
+ struct rdt_resource *r = resctrl_arch_get_resource(RDT_RESOURCE_L3);
+
+ if (r->cache.io_alloc_capable)
+ resctrl_file_fflags_init("io_alloc", RFTYPE_CTRL_INFO |
+ RFTYPE_RES_CACHE);
+}
+
void resctrl_file_fflags_init(const char *config, unsigned long fflags)
{
struct rftype *rft;
@@ -4249,6 +4269,8 @@ int resctrl_init(void)
thread_throttle_mode_init();
+ io_alloc_init();
+
ret = resctrl_mon_resource_init();
if (ret)
return ret;
--
2.34.1
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH v8 05/10] fs/resctrl: Introduce interface to display "io_alloc" support
2025-08-05 23:30 ` [PATCH v8 05/10] fs/resctrl: Introduce interface to display "io_alloc" support Babu Moger
@ 2025-08-08 1:48 ` Reinette Chatre
2025-08-22 22:12 ` Moger, Babu
0 siblings, 1 reply; 34+ messages in thread
From: Reinette Chatre @ 2025-08-08 1:48 UTC (permalink / raw)
To: Babu Moger, corbet, tony.luck, Dave.Martin, james.morse, tglx,
mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Babu,
On 8/5/25 4:30 PM, Babu Moger wrote:
> "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 <babu.moger@amd.com>
> ---
...
> ---
> Documentation/filesystems/resctrl.rst | 29 +++++++++++++++++++++++++++
> fs/resctrl/ctrlmondata.c | 21 +++++++++++++++++++
> fs/resctrl/internal.h | 5 +++++
> fs/resctrl/rdtgroup.c | 24 +++++++++++++++++++++-
> 4 files changed, 78 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
> index f08699030312..fff7e04d1e2a 100644
> --- a/Documentation/filesystems/resctrl.rst
> +++ b/Documentation/filesystems/resctrl.rst
> @@ -136,6 +136,35 @@ 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":
> + Portions of cache used for allocation of I/O traffic
> + cannot be configured.
To help distinguish difference between "disabled" and "not supported" it may be useful
to prepend something like "Resource supports "io_alloc" but the feature is disabled."
> + "enabled":
> + 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.
> +
> + 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, the io_alloc feature is supported by the L3 Smart
drop "the"?
> + Data Cache Injection Allocation Enforcement (SDCIAE). The CLOSID for
> + io_alloc is the highest CLOSID supported by the resource. When
> + 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:
>
Code looks good to me.
Reinette
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v8 05/10] fs/resctrl: Introduce interface to display "io_alloc" support
2025-08-08 1:48 ` Reinette Chatre
@ 2025-08-22 22:12 ` Moger, Babu
0 siblings, 0 replies; 34+ messages in thread
From: Moger, Babu @ 2025-08-22 22:12 UTC (permalink / raw)
To: Reinette Chatre, corbet, tony.luck, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Reinette,
On 8/7/2025 8:48 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 8/5/25 4:30 PM, Babu Moger wrote:
>> "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 <babu.moger@amd.com>
>> ---
> ...
>
>> ---
>> Documentation/filesystems/resctrl.rst | 29 +++++++++++++++++++++++++++
>> fs/resctrl/ctrlmondata.c | 21 +++++++++++++++++++
>> fs/resctrl/internal.h | 5 +++++
>> fs/resctrl/rdtgroup.c | 24 +++++++++++++++++++++-
>> 4 files changed, 78 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
>> index f08699030312..fff7e04d1e2a 100644
>> --- a/Documentation/filesystems/resctrl.rst
>> +++ b/Documentation/filesystems/resctrl.rst
>> @@ -136,6 +136,35 @@ 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":
>> + Portions of cache used for allocation of I/O traffic
>> + cannot be configured.
> To help distinguish difference between "disabled" and "not supported" it may be useful
> to prepend something like "Resource supports "io_alloc" but the feature is disabled."
Sure. Added it now.
>
>> + "enabled":
>> + 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.
>> +
>> + 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, the io_alloc feature is supported by the L3 Smart
> drop "the"?
Sure.
>
>> + Data Cache Injection Allocation Enforcement (SDCIAE). The CLOSID for
>> + io_alloc is the highest CLOSID supported by the resource. When
>> + 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:
>>
> Code looks good to me.
>
Thanks
Babu
>
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v8 06/10] fs/resctrl: Add user interface to enable/disable io_alloc feature
2025-08-05 23:30 [PATCH v8 00/10] x86,fs/resctrl: Support L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE) Babu Moger
` (4 preceding siblings ...)
2025-08-05 23:30 ` [PATCH v8 05/10] fs/resctrl: Introduce interface to display "io_alloc" support Babu Moger
@ 2025-08-05 23:30 ` Babu Moger
2025-08-08 1:49 ` Reinette Chatre
2025-08-21 5:02 ` Gautham R. Shenoy
2025-08-05 23:30 ` [PATCH v8 07/10] fs/resctrl: Introduce interface to display io_alloc CBMs Babu Moger
` (3 subsequent siblings)
9 siblings, 2 replies; 34+ messages in thread
From: Babu Moger @ 2025-08-05 23:30 UTC (permalink / raw)
To: corbet, tony.luck, reinette.chatre, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, babu.moger,
yosry.ahmed, sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
"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.
Signed-off-by: Babu Moger <babu.moger@amd.com>
---
v8: Updated the changelog.
Renamed resctrl_io_alloc_init_cat() to resctrl_io_alloc_init_cbm().
Moved resctrl_io_alloc_write() and all its dependancies to fs/resctrl/ctrlmondata.c.
Added prototypes for all the functions in fs/resctrl/internal.h.
v7: Separated resctrl_io_alloc_show and bit_usage changes in two separate
patches.
Added resctrl_io_alloc_closid_supported() to verify io_alloc CLOSID.
Initialized the schema for both CDP_DATA and CDP_CODE when CDP is enabled.
v6: Changed the subject to fs/resctrl:
v5: Resolved conflicts due to recent resctrl FS/ARCH code restructure.
Used rdt_kn_name to get the rdtgroup name instead of accesssing it directly
while printing group name used by the io_alloc_closid.
Updated bit_usage to reflect the io_alloc CBM as discussed in the thread:
https://lore.kernel.org/lkml/3ca0a5dc-ad9c-4767-9011-b79d986e1e8d@intel.com/
Modified rdt_bit_usage_show() to read io_alloc_cbm in hw_shareable, ensuring
that bit_usage accurately represents the CBMs.
Updated the code to modify io_alloc either with L3CODE or L3DATA.
https://lore.kernel.org/lkml/c00c00ea-a9ac-4c56-961c-dc5bf633476b@intel.com/
v4: Updated the change log.
Updated the user doc.
The "io_alloc" interface will report "enabled/disabled/not supported".
Updated resctrl_io_alloc_closid_get() to verify the max closid availability.
Updated the documentation for "shareable_bits" and "bit_usage".
Introduced io_alloc_init() to initialize fflags.
Printed the group name when io_alloc enablement fails.
NOTE: io_alloc is about specific CLOS. rdt_bit_usage_show() is not designed
handle bit_usage for specific CLOS. Its about overall system. So, we cannot
really tell the user which CLOS is shared across both hardware and software.
We need to discuss this.
v3: Rewrote the change to make it generic.
Rewrote the documentation in resctrl.rst to be generic and added
AMD feature details in the end.
Added the check to verify if MAX CLOSID availability on the system.
Added CDP check to make sure io_alloc is configured in CDP_CODE.
Added resctrl_io_alloc_closid_free() to free the io_alloc CLOSID.
Added errors in few cases when CLOSID allocation fails.
Fixes splat reported when info/L3/bit_usage is accesed when io_alloc
is enabled.
https://lore.kernel.org/lkml/SJ1PR11MB60837B532254E7B23BC27E84FC052@SJ1PR11MB6083.namprd11.prod.outlook.com/
v2: Renamed the feature to "io_alloc".
Added generic texts for the feature in commit log and resctrl.rst doc.
Added resctrl_io_alloc_init_cat() to initialize io_alloc to default
values when enabled.
Fixed io_alloc show functinality to display only on L3 resource.
---
Documentation/filesystems/resctrl.rst | 8 ++
fs/resctrl/ctrlmondata.c | 137 ++++++++++++++++++++++++++
fs/resctrl/internal.h | 11 +++
fs/resctrl/rdtgroup.c | 24 ++++-
4 files changed, 177 insertions(+), 3 deletions(-)
diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
index fff7e04d1e2a..bd0a633afbb9 100644
--- a/Documentation/filesystems/resctrl.rst
+++ b/Documentation/filesystems/resctrl.rst
@@ -150,6 +150,14 @@ related to allocation:
"not supported":
Support not available for this resource.
+ The feature can be modified by writing to the interface, for example:
+
+ To enable:
+ # echo 1 > /sys/fs/resctrl/info/L3/io_alloc
+
+ To disable:
+ # echo 0 > /sys/fs/resctrl/info/L3/io_alloc
+
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
diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
index d495a5d5c9d5..bf982eab7b18 100644
--- a/fs/resctrl/ctrlmondata.c
+++ b/fs/resctrl/ctrlmondata.c
@@ -685,3 +685,140 @@ int resctrl_io_alloc_show(struct kernfs_open_file *of, struct seq_file *seq, voi
return 0;
}
+
+/*
+ * resctrl_io_alloc_closid_supported() - io_alloc feature utilizes the
+ * highest CLOSID value to direct I/O traffic. Ensure that io_alloc_closid
+ * is in the supported range.
+ */
+static bool resctrl_io_alloc_closid_supported(u32 io_alloc_closid)
+{
+ return io_alloc_closid < closids_supported();
+}
+
+static struct resctrl_schema *resctrl_get_schema(enum resctrl_conf_type type)
+{
+ struct resctrl_schema *schema;
+
+ list_for_each_entry(schema, &resctrl_schema_all, list) {
+ if (schema->conf_type == type)
+ return schema;
+ }
+
+ return NULL;
+}
+
+/*
+ * Initialize io_alloc CLOSID cache resource CBM with all usable (shared
+ * and unused) cache portions.
+ */
+static int resctrl_io_alloc_init_cbm(struct resctrl_schema *s, u32 closid)
+{
+ struct rdt_resource *r = s->res;
+ enum resctrl_conf_type peer_type;
+ struct resctrl_schema *peer_s;
+ int ret;
+
+ rdt_staged_configs_clear();
+
+ ret = rdtgroup_init_cat(s, closid);
+ if (ret < 0)
+ goto out;
+
+ /* Initialize schema for both CDP_DATA and CDP_CODE when CDP is enabled */
+ if (resctrl_arch_get_cdp_enabled(r->rid)) {
+ peer_type = resctrl_peer_type(s->conf_type);
+ peer_s = resctrl_get_schema(peer_type);
+ if (peer_s) {
+ ret = rdtgroup_init_cat(peer_s, closid);
+ if (ret < 0)
+ goto out;
+ }
+ }
+
+ ret = resctrl_arch_update_domains(r, closid);
+
+out:
+ rdt_staged_configs_clear();
+ return ret;
+}
+
+/*
+ * resctrl_io_alloc_closid() - io_alloc feature routes I/O traffic using
+ * the highest available CLOSID. Retrieve the maximum CLOSID supported by the
+ * resource. Note that if Code Data Prioritization (CDP) is enabled, the number
+ * of available CLOSIDs is reduced by half.
+ */
+static u32 resctrl_io_alloc_closid(struct rdt_resource *r)
+{
+ if (resctrl_arch_get_cdp_enabled(r->rid))
+ return resctrl_arch_get_num_closid(r) / 2 - 1;
+ else
+ return resctrl_arch_get_num_closid(r) - 1;
+}
+
+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;
+ }
+
+ 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",
+ io_alloc_closid);
+ ret = -EINVAL;
+ goto out_unlock;
+ }
+
+ /* If the feature is already up to date, no action is needed. */
+ if (resctrl_arch_get_io_alloc_enabled(r) == enable)
+ 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",
+ 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);
+ }
+
+ ret = resctrl_arch_io_alloc_enable(r, enable);
+
+out_unlock:
+ mutex_unlock(&rdtgroup_mutex);
+ cpus_read_unlock();
+
+ return ret ?: nbytes;
+}
diff --git a/fs/resctrl/internal.h b/fs/resctrl/internal.h
index 1a4543c2b988..335def7af1f6 100644
--- a/fs/resctrl/internal.h
+++ b/fs/resctrl/internal.h
@@ -373,6 +373,8 @@ void rdt_staged_configs_clear(void);
bool closid_allocated(unsigned int closid);
+bool closid_alloc_fixed(u32 closid);
+
int resctrl_find_cleanest_closid(void);
int resctrl_io_alloc_show(struct kernfs_open_file *of, struct seq_file *seq,
@@ -380,6 +382,15 @@ int resctrl_io_alloc_show(struct kernfs_open_file *of, struct seq_file *seq,
void *rdt_kn_parent_priv(struct kernfs_node *kn);
+int rdtgroup_init_cat(struct resctrl_schema *s, u32 closid);
+
+enum resctrl_conf_type resctrl_peer_type(enum resctrl_conf_type my_type);
+
+ssize_t resctrl_io_alloc_write(struct kernfs_open_file *of, char *buf,
+ size_t nbytes, loff_t off);
+
+const char *rdtgroup_name_by_closid(int closid);
+
#ifdef CONFIG_RESCTRL_FS_PSEUDO_LOCK
int rdtgroup_locksetup_enter(struct rdtgroup *rdtgrp);
diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index acc9edc1a268..380ebc86c748 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -232,6 +232,11 @@ bool closid_allocated(unsigned int closid)
return !test_bit(closid, closid_free_map);
}
+bool closid_alloc_fixed(u32 closid)
+{
+ return __test_and_clear_bit(closid, closid_free_map);
+}
+
/**
* rdtgroup_mode_by_closid - Return mode of resource group with closid
* @closid: closid if the resource group
@@ -1250,7 +1255,7 @@ static int rdtgroup_mode_show(struct kernfs_open_file *of,
return 0;
}
-static enum resctrl_conf_type resctrl_peer_type(enum resctrl_conf_type my_type)
+enum resctrl_conf_type resctrl_peer_type(enum resctrl_conf_type my_type)
{
switch (my_type) {
case CDP_CODE:
@@ -1803,6 +1808,18 @@ static ssize_t mbm_local_bytes_config_write(struct kernfs_open_file *of,
return ret ?: nbytes;
}
+const char *rdtgroup_name_by_closid(int closid)
+{
+ struct rdtgroup *rdtgrp;
+
+ list_for_each_entry(rdtgrp, &rdt_all_groups, rdtgroup_list) {
+ if (rdtgrp->closid == closid)
+ return rdt_kn_name(rdtgrp->kn);
+ }
+
+ return NULL;
+}
+
/* rdtgroup information files for one cache resource. */
static struct rftype res_common_files[] = {
{
@@ -1895,9 +1912,10 @@ static struct rftype res_common_files[] = {
},
{
.name = "io_alloc",
- .mode = 0444,
+ .mode = 0644,
.kf_ops = &rdtgroup_kf_single_ops,
.seq_show = resctrl_io_alloc_show,
+ .write = resctrl_io_alloc_write,
},
{
.name = "max_threshold_occupancy",
@@ -3365,7 +3383,7 @@ static int __init_one_rdt_domain(struct rdt_ctrl_domain *d, struct resctrl_schem
* If there are no more shareable bits available on any domain then
* the entire allocation will fail.
*/
-static int rdtgroup_init_cat(struct resctrl_schema *s, u32 closid)
+int rdtgroup_init_cat(struct resctrl_schema *s, u32 closid)
{
struct rdt_ctrl_domain *d;
int ret;
--
2.34.1
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH v8 06/10] fs/resctrl: Add user interface to enable/disable io_alloc feature
2025-08-05 23:30 ` [PATCH v8 06/10] fs/resctrl: Add user interface to enable/disable io_alloc feature Babu Moger
@ 2025-08-08 1:49 ` Reinette Chatre
2025-08-22 22:53 ` Moger, Babu
2025-08-21 5:02 ` Gautham R. Shenoy
1 sibling, 1 reply; 34+ messages in thread
From: Reinette Chatre @ 2025-08-08 1:49 UTC (permalink / raw)
To: Babu Moger, corbet, tony.luck, Dave.Martin, james.morse, tglx,
mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Babu,
On 8/5/25 4:30 PM, Babu Moger wrote:
> "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.
Please include high level overview of what this patch does to enable
and disable io_alloc. Doing so will help connect why the changelog contains
information about CLOSID management.
> diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
> index d495a5d5c9d5..bf982eab7b18 100644
> --- a/fs/resctrl/ctrlmondata.c
> +++ b/fs/resctrl/ctrlmondata.c
> @@ -685,3 +685,140 @@ int resctrl_io_alloc_show(struct kernfs_open_file *of, struct seq_file *seq, voi
>
> return 0;
> }
> +
> +/*
> + * resctrl_io_alloc_closid_supported() - io_alloc feature utilizes the
> + * highest CLOSID value to direct I/O traffic. Ensure that io_alloc_closid
> + * is in the supported range.
> + */
> +static bool resctrl_io_alloc_closid_supported(u32 io_alloc_closid)
> +{
> + return io_alloc_closid < closids_supported();
> +}
> +
> +static struct resctrl_schema *resctrl_get_schema(enum resctrl_conf_type type)
> +{
> + struct resctrl_schema *schema;
> +
> + list_for_each_entry(schema, &resctrl_schema_all, list) {
> + if (schema->conf_type == type)
> + return schema;
This does not look right. More than one resource can have the same configuration type, no?
Think about L2 and L3 having CDP enabled ...
Looks like this is missing a resource type as parameter and a check for the resource ...
but is this function even necessary (more below)?
> + }
> +
> + return NULL;
> +}
> +
> +/*
> + * Initialize io_alloc CLOSID cache resource CBM with all usable (shared
> + * and unused) cache portions.
> + */
> +static int resctrl_io_alloc_init_cbm(struct resctrl_schema *s, u32 closid)
> +{
> + struct rdt_resource *r = s->res;
Needs reverse fir.
> + enum resctrl_conf_type peer_type;
> + struct resctrl_schema *peer_s;
> + int ret;
> +
> + rdt_staged_configs_clear();
> +
> + ret = rdtgroup_init_cat(s, closid);
> + if (ret < 0)
> + goto out;
> +
> + /* Initialize schema for both CDP_DATA and CDP_CODE when CDP is enabled */
> + if (resctrl_arch_get_cdp_enabled(r->rid)) {
> + peer_type = resctrl_peer_type(s->conf_type);
> + peer_s = resctrl_get_schema(peer_type);
> + if (peer_s) {
> + ret = rdtgroup_init_cat(peer_s, closid);
This is unexpected. In v7 I suggested that when parsing the CBM of one of the CDP
resources it is not necessary to do so again for the peer. The CBM can be
parsed *once* and the configuration just copied over. See:
https://lore.kernel.org/lkml/82045638-2b26-4682-9374-1c3e400a580a@intel.com/
Generally when feedback is provided it is good to check all places in series where
it is relevant. oh ... but looking ahead you ignored the feedback in the patch
it was given also :(
Reinette
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v8 06/10] fs/resctrl: Add user interface to enable/disable io_alloc feature
2025-08-08 1:49 ` Reinette Chatre
@ 2025-08-22 22:53 ` Moger, Babu
2025-08-27 20:39 ` Moger, Babu
0 siblings, 1 reply; 34+ messages in thread
From: Moger, Babu @ 2025-08-22 22:53 UTC (permalink / raw)
To: Reinette Chatre, corbet, tony.luck, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Reinette,
On 8/7/2025 8:49 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 8/5/25 4:30 PM, Babu Moger wrote:
>> "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.
> Please include high level overview of what this patch does to enable
> and disable io_alloc. Doing so will help connect why the changelog contains
> information about CLOSID management.
Sure.
>
>> diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
>> index d495a5d5c9d5..bf982eab7b18 100644
>> --- a/fs/resctrl/ctrlmondata.c
>> +++ b/fs/resctrl/ctrlmondata.c
>> @@ -685,3 +685,140 @@ int resctrl_io_alloc_show(struct kernfs_open_file *of, struct seq_file *seq, voi
>>
>> return 0;
>> }
>> +
>> +/*
>> + * resctrl_io_alloc_closid_supported() - io_alloc feature utilizes the
>> + * highest CLOSID value to direct I/O traffic. Ensure that io_alloc_closid
>> + * is in the supported range.
>> + */
>> +static bool resctrl_io_alloc_closid_supported(u32 io_alloc_closid)
>> +{
>> + return io_alloc_closid < closids_supported();
>> +}
>> +
>> +static struct resctrl_schema *resctrl_get_schema(enum resctrl_conf_type type)
>> +{
>> + struct resctrl_schema *schema;
>> +
>> + list_for_each_entry(schema, &resctrl_schema_all, list) {
>> + if (schema->conf_type == type)
>> + return schema;
> This does not look right. More than one resource can have the same configuration type, no?
> Think about L2 and L3 having CDP enabled ...
> Looks like this is missing a resource type as parameter and a check for the resource ...
> but is this function even necessary (more below)?
May not be required. Comments below.
>
>> + }
>> +
>> + return NULL;
>> +}
>> +
>> +/*
>> + * Initialize io_alloc CLOSID cache resource CBM with all usable (shared
>> + * and unused) cache portions.
>> + */
>> +static int resctrl_io_alloc_init_cbm(struct resctrl_schema *s, u32 closid)
>> +{
>> + struct rdt_resource *r = s->res;
> Needs reverse fir.
Sure.
>
>> + enum resctrl_conf_type peer_type;
>> + struct resctrl_schema *peer_s;
>> + int ret;
>> +
>> + rdt_staged_configs_clear();
>> +
>> + ret = rdtgroup_init_cat(s, closid);
>> + if (ret < 0)
>> + goto out;
>> +
>> + /* Initialize schema for both CDP_DATA and CDP_CODE when CDP is enabled */
>> + if (resctrl_arch_get_cdp_enabled(r->rid)) {
>> + peer_type = resctrl_peer_type(s->conf_type);
>> + peer_s = resctrl_get_schema(peer_type);
>> + if (peer_s) {
>> + ret = rdtgroup_init_cat(peer_s, closid);
> This is unexpected. In v7 I suggested that when parsing the CBM of one of the CDP
> resources it is not necessary to do so again for the peer. The CBM can be
> parsed *once* and the configuration just copied over. See:
> https://lore.kernel.org/lkml/82045638-2b26-4682-9374-1c3e400a580a@intel.com/
Let met try to understand.
So, rdtgroup_init_cat() sets up the staged _config for the specific CDP
type for all the domains.
We need to apply those staged_configs to its peer type on all the domains.
Something like this?
/* Initialize staged_config of the peer type when CDP is enabled */
if (resctrl_arch_get_cdp_enabled(r->rid)) {
list_for_each_entry(d, &s->res->ctrl_domains, hdr.list) {
cfg = &d->staged_config[s->conf_type];
cfg_peer = &d->staged_config[peer_type];
cfg_peer->new_ctrl = cfg->new_ctrl;
cfg_peer->have_new_ctrl = cfg->have_new_ctrl;
}
}
>
> Generally when feedback is provided it is good to check all places in series where
> it is relevant. oh ... but looking ahead you ignored the feedback in the patch
> it was given also :(
My bad.
I will address that.
Thanks
Babu
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v8 06/10] fs/resctrl: Add user interface to enable/disable io_alloc feature
2025-08-22 22:53 ` Moger, Babu
@ 2025-08-27 20:39 ` Moger, Babu
2025-08-29 2:47 ` Reinette Chatre
0 siblings, 1 reply; 34+ messages in thread
From: Moger, Babu @ 2025-08-27 20:39 UTC (permalink / raw)
To: Reinette Chatre, corbet, tony.luck, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
On 8/22/25 17:53, Moger, Babu wrote:
> Hi Reinette,
>
> On 8/7/2025 8:49 PM, Reinette Chatre wrote:
>> Hi Babu,
>>
>> On 8/5/25 4:30 PM, Babu Moger wrote:
>>> "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.
>> Please include high level overview of what this patch does to enable
>> and disable io_alloc. Doing so will help connect why the changelog contains
>> information about CLOSID management.
>
>
> Sure.
>
>>
>>> diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
>>> index d495a5d5c9d5..bf982eab7b18 100644
>>> --- a/fs/resctrl/ctrlmondata.c
>>> +++ b/fs/resctrl/ctrlmondata.c
>>> @@ -685,3 +685,140 @@ int resctrl_io_alloc_show(struct kernfs_open_file
>>> *of, struct seq_file *seq, voi
>>> return 0;
>>> }
>>> +
>>> +/*
>>> + * resctrl_io_alloc_closid_supported() - io_alloc feature utilizes the
>>> + * highest CLOSID value to direct I/O traffic. Ensure that
>>> io_alloc_closid
>>> + * is in the supported range.
>>> + */
>>> +static bool resctrl_io_alloc_closid_supported(u32 io_alloc_closid)
>>> +{
>>> + return io_alloc_closid < closids_supported();
>>> +}
>>> +
>>> +static struct resctrl_schema *resctrl_get_schema(enum
>>> resctrl_conf_type type)
>>> +{
>>> + struct resctrl_schema *schema;
>>> +
>>> + list_for_each_entry(schema, &resctrl_schema_all, list) {
>>> + if (schema->conf_type == type)
>>> + return schema;
>> This does not look right. More than one resource can have the same
>> configuration type, no?
>> Think about L2 and L3 having CDP enabled ...
>> Looks like this is missing a resource type as parameter and a check for
>> the resource ...
>> but is this function even necessary (more below)?
>
> May not be required. Comments below.
>
>>
>>> + }
>>> +
>>> + return NULL;
>>> +}
>>> +
>>> +/*
>>> + * Initialize io_alloc CLOSID cache resource CBM with all usable (shared
>>> + * and unused) cache portions.
>>> + */
>>> +static int resctrl_io_alloc_init_cbm(struct resctrl_schema *s, u32
>>> closid)
>>> +{
>>> + struct rdt_resource *r = s->res;
>> Needs reverse fir.
>
>
> Sure.
>
>>
>>> + enum resctrl_conf_type peer_type;
>>> + struct resctrl_schema *peer_s;
>>> + int ret;
>>> +
>>> + rdt_staged_configs_clear();
>>> +
>>> + ret = rdtgroup_init_cat(s, closid);
>>> + if (ret < 0)
>>> + goto out;
>>> +
>>> + /* Initialize schema for both CDP_DATA and CDP_CODE when CDP is
>>> enabled */
>>> + if (resctrl_arch_get_cdp_enabled(r->rid)) {
>>> + peer_type = resctrl_peer_type(s->conf_type);
>>> + peer_s = resctrl_get_schema(peer_type);
>>> + if (peer_s) {
>>> + ret = rdtgroup_init_cat(peer_s, closid);
>> This is unexpected. In v7 I suggested that when parsing the CBM of one
>> of the CDP
>> resources it is not necessary to do so again for the peer. The CBM can be
>> parsed *once* and the configuration just copied over. See:
>> https://lore.kernel.org/
>> lkml/82045638-2b26-4682-9374-1c3e400a580a@intel.com/
>
> Let met try to understand.
>
> So, rdtgroup_init_cat() sets up the staged _config for the specific CDP
> type for all the domains.
>
> We need to apply those staged_configs to its peer type on all the domains.
>
> Something like this?
>
> /* Initialize staged_config of the peer type when CDP is enabled */
> if (resctrl_arch_get_cdp_enabled(r->rid)) {
> list_for_each_entry(d, &s->res->ctrl_domains, hdr.list) {
> cfg = &d->staged_config[s->conf_type];
> cfg_peer = &d->staged_config[peer_type];
> cfg_peer->new_ctrl = cfg->new_ctrl;
> cfg_peer->have_new_ctrl = cfg->have_new_ctrl;
> }
> }
>
Replaced with following snippet.
/* Initialize schema for both CDP_DATA and CDP_CODE when CDP is enabled */
+ if (resctrl_arch_get_cdp_enabled(r->rid)) {
+ peer_type = resctrl_peer_type(s->conf_type);
+ list_for_each_entry(d, &s->res->ctrl_domains, hdr.list)
+ memcpy(&d->staged_config[peer_type],
+ &d->staged_config[s->conf_type],
+ sizeof(*d->staged_config));
+ }
>
>>
>> Generally when feedback is provided it is good to check all places in
>> series where
>> it is relevant. oh ... but looking ahead you ignored the feedback in the
>> patch
>> it was given also :(
>
>
> My bad.
>
> I will address that.
>
> Thanks
>
> Babu
>
>
--
Thanks
Babu Moger
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v8 06/10] fs/resctrl: Add user interface to enable/disable io_alloc feature
2025-08-27 20:39 ` Moger, Babu
@ 2025-08-29 2:47 ` Reinette Chatre
2025-09-02 16:20 ` Moger, Babu
0 siblings, 1 reply; 34+ messages in thread
From: Reinette Chatre @ 2025-08-29 2:47 UTC (permalink / raw)
To: Moger, Babu, corbet, tony.luck, Dave.Martin, james.morse, tglx,
mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Babu,
On 8/27/25 1:39 PM, Moger, Babu wrote:
> On 8/22/25 17:53, Moger, Babu wrote:
>> On 8/7/2025 8:49 PM, Reinette Chatre wrote:
>>> On 8/5/25 4:30 PM, Babu Moger wrote:
>>>
>>>> + enum resctrl_conf_type peer_type;
>>>> + struct resctrl_schema *peer_s;
>>>> + int ret;
>>>> +
>>>> + rdt_staged_configs_clear();
>>>> +
>>>> + ret = rdtgroup_init_cat(s, closid);
>>>> + if (ret < 0)
>>>> + goto out;
>>>> +
>>>> + /* Initialize schema for both CDP_DATA and CDP_CODE when CDP is
>>>> enabled */
>>>> + if (resctrl_arch_get_cdp_enabled(r->rid)) {
>>>> + peer_type = resctrl_peer_type(s->conf_type);
>>>> + peer_s = resctrl_get_schema(peer_type);
>>>> + if (peer_s) {
>>>> + ret = rdtgroup_init_cat(peer_s, closid);
>>> This is unexpected. In v7 I suggested that when parsing the CBM of one
>>> of the CDP
>>> resources it is not necessary to do so again for the peer. The CBM can be
>>> parsed *once* and the configuration just copied over. See:
>>> https://lore.kernel.org/
>>> lkml/82045638-2b26-4682-9374-1c3e400a580a@intel.com/
>>
>> Let met try to understand.
>>
>> So, rdtgroup_init_cat() sets up the staged _config for the specific CDP
>> type for all the domains.
>>
>> We need to apply those staged_configs to its peer type on all the domains.
To put it more directly, this implementation keeps the CBM of CDP_CODE and
CDP_DATA in sync. Skipping the unnecessary and duplicate parsing and instead
copying the CBM from one to the other makes that obvious.
>>
>> Something like this?
>>
>> /* Initialize staged_config of the peer type when CDP is enabled */
>> if (resctrl_arch_get_cdp_enabled(r->rid)) {
>> list_for_each_entry(d, &s->res->ctrl_domains, hdr.list) {
>> cfg = &d->staged_config[s->conf_type];
>> cfg_peer = &d->staged_config[peer_type];
>> cfg_peer->new_ctrl = cfg->new_ctrl;
>> cfg_peer->have_new_ctrl = cfg->have_new_ctrl;
>> }
>> }
>>
>
> Replaced with following snippet.
>
> /* Initialize schema for both CDP_DATA and CDP_CODE when CDP is enabled */
Could this be more specific? For example,
"Keep CDP_CODE and CDP_DATA of io_alloc CLOSID's CBM in sync."
> + if (resctrl_arch_get_cdp_enabled(r->rid)) {
> + peer_type = resctrl_peer_type(s->conf_type);
> + list_for_each_entry(d, &s->res->ctrl_domains, hdr.list)
> + memcpy(&d->staged_config[peer_type],
> + &d->staged_config[s->conf_type],
> + sizeof(*d->staged_config));
This looks good to me. To make it obvious what types are dealt with this
can instead use sizeof(d->staged_config[0]).
Thank you.
Reinette
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v8 06/10] fs/resctrl: Add user interface to enable/disable io_alloc feature
2025-08-29 2:47 ` Reinette Chatre
@ 2025-09-02 16:20 ` Moger, Babu
0 siblings, 0 replies; 34+ messages in thread
From: Moger, Babu @ 2025-09-02 16:20 UTC (permalink / raw)
To: Reinette Chatre, corbet, tony.luck, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Reinette,
On 8/28/2025 9:47 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 8/27/25 1:39 PM, Moger, Babu wrote:
>> On 8/22/25 17:53, Moger, Babu wrote:
>>> On 8/7/2025 8:49 PM, Reinette Chatre wrote:
>>>> On 8/5/25 4:30 PM, Babu Moger wrote:
>>>>> + enum resctrl_conf_type peer_type;
>>>>> + struct resctrl_schema *peer_s;
>>>>> + int ret;
>>>>> +
>>>>> + rdt_staged_configs_clear();
>>>>> +
>>>>> + ret = rdtgroup_init_cat(s, closid);
>>>>> + if (ret < 0)
>>>>> + goto out;
>>>>> +
>>>>> + /* Initialize schema for both CDP_DATA and CDP_CODE when CDP is
>>>>> enabled */
>>>>> + if (resctrl_arch_get_cdp_enabled(r->rid)) {
>>>>> + peer_type = resctrl_peer_type(s->conf_type);
>>>>> + peer_s = resctrl_get_schema(peer_type);
>>>>> + if (peer_s) {
>>>>> + ret = rdtgroup_init_cat(peer_s, closid);
>>>> This is unexpected. In v7 I suggested that when parsing the CBM of one
>>>> of the CDP
>>>> resources it is not necessary to do so again for the peer. The CBM can be
>>>> parsed *once* and the configuration just copied over. See:
>>>> https://lore.kernel.org/
>>>> lkml/82045638-2b26-4682-9374-1c3e400a580a@intel.com/
>>> Let met try to understand.
>>>
>>> So, rdtgroup_init_cat() sets up the staged _config for the specific CDP
>>> type for all the domains.
>>>
>>> We need to apply those staged_configs to its peer type on all the domains.
> To put it more directly, this implementation keeps the CBM of CDP_CODE and
> CDP_DATA in sync. Skipping the unnecessary and duplicate parsing and instead
> copying the CBM from one to the other makes that obvious.
Got it.
>
>>> Something like this?
>>>
>>> /* Initialize staged_config of the peer type when CDP is enabled */
>>> if (resctrl_arch_get_cdp_enabled(r->rid)) {
>>> list_for_each_entry(d, &s->res->ctrl_domains, hdr.list) {
>>> cfg = &d->staged_config[s->conf_type];
>>> cfg_peer = &d->staged_config[peer_type];
>>> cfg_peer->new_ctrl = cfg->new_ctrl;
>>> cfg_peer->have_new_ctrl = cfg->have_new_ctrl;
>>> }
>>> }
>>>
>> Replaced with following snippet.
>>
>> /* Initialize schema for both CDP_DATA and CDP_CODE when CDP is enabled */
> Could this be more specific? For example,
> "Keep CDP_CODE and CDP_DATA of io_alloc CLOSID's CBM in sync."
Sure.
>
>> + if (resctrl_arch_get_cdp_enabled(r->rid)) {
>> + peer_type = resctrl_peer_type(s->conf_type);
>> + list_for_each_entry(d, &s->res->ctrl_domains, hdr.list)
>> + memcpy(&d->staged_config[peer_type],
>> + &d->staged_config[s->conf_type],
>> + sizeof(*d->staged_config));
> This looks good to me. To make it obvious what types are dealt with this
> can instead use sizeof(d->staged_config[0]).
Sure. Thanks
Babu
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v8 06/10] fs/resctrl: Add user interface to enable/disable io_alloc feature
2025-08-05 23:30 ` [PATCH v8 06/10] fs/resctrl: Add user interface to enable/disable io_alloc feature Babu Moger
2025-08-08 1:49 ` Reinette Chatre
@ 2025-08-21 5:02 ` Gautham R. Shenoy
2025-08-22 23:10 ` Moger, Babu
1 sibling, 1 reply; 34+ messages in thread
From: Gautham R. Shenoy @ 2025-08-21 5:02 UTC (permalink / raw)
To: Babu Moger
Cc: corbet, tony.luck, reinette.chatre, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen, x86, hpa, akpm, paulmck, rostedt,
Neeraj.Upadhyay, david, arnd, fvdl, seanjc, thomas.lendacky,
pawan.kumar.gupta, yosry.ahmed, sohil.mehta, xin, kai.huang,
xiaoyao.li, peterz, me, mario.limonciello, xin3.li, ebiggers, ak,
chang.seok.bae, andrew.cooper3, perry.yuan, linux-doc,
linux-kernel, manali.shukla
Hello Babu,
On Tue, Aug 05, 2025 at 06:30:26PM -0500, Babu Moger wrote:
> "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.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
[..snip..]
> +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;
> + }
> +
> + 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",
> + io_alloc_closid);
> + ret = -EINVAL;
> + goto out_unlock;
> + }
> +
> + /* If the feature is already up to date, no action is needed. */
> + if (resctrl_arch_get_io_alloc_enabled(r) == enable)
> + goto out_unlock;
Does it make sense to move this check before calling resctrl_io_alloc_closid(r) ?
> +
> + 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",
> + 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);
> + }
> +
> + ret = resctrl_arch_io_alloc_enable(r, enable);
> +
> +out_unlock:
> + mutex_unlock(&rdtgroup_mutex);
> + cpus_read_unlock();
> +
> + return ret ?: nbytes;
> +}
[..snip..]
--
Thanks and Regards
gautham.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v8 06/10] fs/resctrl: Add user interface to enable/disable io_alloc feature
2025-08-21 5:02 ` Gautham R. Shenoy
@ 2025-08-22 23:10 ` Moger, Babu
0 siblings, 0 replies; 34+ messages in thread
From: Moger, Babu @ 2025-08-22 23:10 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: corbet, tony.luck, reinette.chatre, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen, x86, hpa, akpm, paulmck, rostedt,
Neeraj.Upadhyay, david, arnd, fvdl, seanjc, thomas.lendacky,
pawan.kumar.gupta, yosry.ahmed, sohil.mehta, xin, kai.huang,
xiaoyao.li, peterz, me, mario.limonciello, xin3.li, ebiggers, ak,
chang.seok.bae, andrew.cooper3, perry.yuan, linux-doc,
linux-kernel, manali.shukla
Hi Gautham,
On 8/21/2025 12:02 AM, Gautham R. Shenoy wrote:
> Hello Babu,
>
> On Tue, Aug 05, 2025 at 06:30:26PM -0500, Babu Moger wrote:
>> "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.
>>
>> Signed-off-by: Babu Moger <babu.moger@amd.com>
> [..snip..]
>
>
>> +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;
>> + }
>> +
>> + 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",
>> + io_alloc_closid);
>> + ret = -EINVAL;
>> + goto out_unlock;
>> + }
>> +
>> + /* If the feature is already up to date, no action is needed. */
>> + if (resctrl_arch_get_io_alloc_enabled(r) == enable)
>> + goto out_unlock;
> Does it make sense to move this check before calling resctrl_io_alloc_closid(r) ?
Sure. We can do that.
Thanks
Babu
>
>
>> +
>> + 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",
>> + 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);
>> + }
>> +
>> + ret = resctrl_arch_io_alloc_enable(r, enable);
>> +
>> +out_unlock:
>> + mutex_unlock(&rdtgroup_mutex);
>> + cpus_read_unlock();
>> +
>> + return ret ?: nbytes;
>> +}
> [..snip..]
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v8 07/10] fs/resctrl: Introduce interface to display io_alloc CBMs
2025-08-05 23:30 [PATCH v8 00/10] x86,fs/resctrl: Support L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE) Babu Moger
` (5 preceding siblings ...)
2025-08-05 23:30 ` [PATCH v8 06/10] fs/resctrl: Add user interface to enable/disable io_alloc feature Babu Moger
@ 2025-08-05 23:30 ` Babu Moger
2025-08-08 1:51 ` Reinette Chatre
2025-08-05 23:30 ` [PATCH v8 08/10] fs/resctrl: Modify rdt_parse_data to pass mode and CLOSID Babu Moger
` (2 subsequent siblings)
9 siblings, 1 reply; 34+ messages in thread
From: Babu Moger @ 2025-08-05 23:30 UTC (permalink / raw)
To: corbet, tony.luck, reinette.chatre, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, babu.moger,
yosry.ahmed, sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
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 CBMs (Capacity Bit Mask) of
io_alloc feature.
The CBM interface file io_alloc_cbm resides in the info directory
(e.g., /sys/fs/resctrl/info/L3/). Displaying the resource name is not
necessary. Pass the resource name to show_doms() and print it only if
the name is valid. For io_alloc, pass NULL 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 must remain synchronized.
rdtgroup_init_cat() function takes both L3CODE and L3DATA into account when
initializing CBMs for new groups. The io_alloc feature adheres to this
same principle, meaning that the Cache Bit Masks (CBMs) accessed through
either L3CODE or L3DATA will reflect identical values.
Signed-off-by: Babu Moger <babu.moger@amd.com>
---
v8: Updated the changelog.
Moved resctrl_io_alloc_cbm_show() to fs/resctrl/ctrlmondata.c.
show_doms is remains static with this change.
v7: Updated changelog.
Updated use doc (resctrl.rst).
Removed if (io_alloc_closid < 0) check. Not required anymore.
v6: Added "io_alloc_cbm" details in user doc resctrl.rst.
Resource name is not printed in CBM now. Corrected the texts about it
in resctrl.rst.
v5: Resolved conflicts due to recent resctrl FS/ARCH code restructure.
Updated show_doms() to print the resource if only it is valid. Pass NULL while
printing io_alloc CBM.
Changed the code to access the CBMs via either L3CODE or L3DATA resources.
v4: Updated the change log.
Added rdtgroup_mutex before rdt_last_cmd_puts().
Returned -ENODEV when resource type is CDP_DATA.
Kept the resource name while printing the CBM (L3:0=fff) that way
I dont have to change show_doms() just for this feature and it is
consistant across all the schemata display.
v3: Minor changes due to changes in resctrl_arch_get_io_alloc_enabled()
and resctrl_io_alloc_closid_get().
Added the check to verify CDP resource type.
Updated the commit log.
v2: Fixed to display only on L3 resources.
Added the locks while processing.
Rename the displat to io_alloc_cbm (from sdciae_cmd).
---
Documentation/filesystems/resctrl.rst | 19 +++++++++++++
fs/resctrl/ctrlmondata.c | 39 ++++++++++++++++++++++++---
fs/resctrl/internal.h | 3 +++
fs/resctrl/rdtgroup.c | 11 +++++++-
4 files changed, 68 insertions(+), 4 deletions(-)
diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
index bd0a633afbb9..3002f7fdb2fe 100644
--- a/Documentation/filesystems/resctrl.rst
+++ b/Documentation/filesystems/resctrl.rst
@@ -173,6 +173,25 @@ related to allocation:
available for general (CPU) cache allocation for both the L3CODE and
L3DATA resources.
+"io_alloc_cbm":
+ CBMs(Capacity Bit Masks) that describe the portions of cache instances
+ to which I/O traffic from supported I/O devices are routed when "io_alloc"
+ is enabled.
+
+ CBMs are displayed in the following format:
+
+ <cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+
+ Example::
+
+ # cat /sys/fs/resctrl/info/L3/io_alloc_cbm
+ 0=ffff;1=ffff
+
+ 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
+ /sys/fs/resctrl/info/L3CODE/io_alloc_cbm and vice versa.
+
Memory bandwidth(MB) subdirectory contains the following files
with respect to allocation:
diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
index bf982eab7b18..edb9dd131eed 100644
--- a/fs/resctrl/ctrlmondata.c
+++ b/fs/resctrl/ctrlmondata.c
@@ -381,7 +381,8 @@ ssize_t rdtgroup_schemata_write(struct kernfs_open_file *of,
return ret ?: nbytes;
}
-static void show_doms(struct seq_file *s, struct resctrl_schema *schema, int closid)
+static void show_doms(struct seq_file *s, struct resctrl_schema *schema,
+ char *resource_name, int closid)
{
struct rdt_resource *r = schema->res;
struct rdt_ctrl_domain *dom;
@@ -391,7 +392,8 @@ static void show_doms(struct seq_file *s, struct resctrl_schema *schema, int clo
/* Walking r->domains, ensure it can't race with cpuhp */
lockdep_assert_cpus_held();
- seq_printf(s, "%*s:", max_name_width, schema->name);
+ if (resource_name)
+ seq_printf(s, "%*s:", max_name_width, resource_name);
list_for_each_entry(dom, &r->ctrl_domains, hdr.list) {
if (sep)
seq_puts(s, ";");
@@ -437,7 +439,7 @@ int rdtgroup_schemata_show(struct kernfs_open_file *of,
closid = rdtgrp->closid;
list_for_each_entry(schema, &resctrl_schema_all, list) {
if (closid < schema->num_closid)
- show_doms(s, schema, closid);
+ show_doms(s, schema, schema->name, closid);
}
}
} else {
@@ -822,3 +824,34 @@ 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;
+ }
+
+ if (!resctrl_arch_get_io_alloc_enabled(r)) {
+ rdt_last_cmd_printf("io_alloc is not enabled on %s\n", s->name);
+ ret = -EINVAL;
+ goto out_unlock;
+ }
+
+ show_doms(seq, s, NULL, resctrl_io_alloc_closid(r));
+
+out_unlock:
+ mutex_unlock(&rdtgroup_mutex);
+ cpus_read_unlock();
+ return ret;
+}
diff --git a/fs/resctrl/internal.h b/fs/resctrl/internal.h
index 335def7af1f6..49934cd3dc40 100644
--- a/fs/resctrl/internal.h
+++ b/fs/resctrl/internal.h
@@ -389,6 +389,9 @@ enum resctrl_conf_type resctrl_peer_type(enum resctrl_conf_type my_type);
ssize_t resctrl_io_alloc_write(struct kernfs_open_file *of, char *buf,
size_t nbytes, loff_t off);
+int resctrl_io_alloc_cbm_show(struct kernfs_open_file *of, struct seq_file *seq,
+ void *v);
+
const char *rdtgroup_name_by_closid(int closid);
#ifdef CONFIG_RESCTRL_FS_PSEUDO_LOCK
diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index 380ebc86c748..6af8ff6c8385 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -1917,6 +1917,12 @@ static struct rftype res_common_files[] = {
.seq_show = resctrl_io_alloc_show,
.write = resctrl_io_alloc_write,
},
+ {
+ .name = "io_alloc_cbm",
+ .mode = 0444,
+ .kf_ops = &rdtgroup_kf_single_ops,
+ .seq_show = resctrl_io_alloc_cbm_show,
+ },
{
.name = "max_threshold_occupancy",
.mode = 0644,
@@ -2095,9 +2101,12 @@ static void io_alloc_init(void)
{
struct rdt_resource *r = resctrl_arch_get_resource(RDT_RESOURCE_L3);
- if (r->cache.io_alloc_capable)
+ if (r->cache.io_alloc_capable) {
resctrl_file_fflags_init("io_alloc", RFTYPE_CTRL_INFO |
RFTYPE_RES_CACHE);
+ resctrl_file_fflags_init("io_alloc_cbm",
+ RFTYPE_CTRL_INFO | RFTYPE_RES_CACHE);
+ }
}
void resctrl_file_fflags_init(const char *config, unsigned long fflags)
--
2.34.1
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH v8 07/10] fs/resctrl: Introduce interface to display io_alloc CBMs
2025-08-05 23:30 ` [PATCH v8 07/10] fs/resctrl: Introduce interface to display io_alloc CBMs Babu Moger
@ 2025-08-08 1:51 ` Reinette Chatre
2025-08-26 18:33 ` Moger, Babu
0 siblings, 1 reply; 34+ messages in thread
From: Reinette Chatre @ 2025-08-08 1:51 UTC (permalink / raw)
To: Babu Moger, corbet, tony.luck, Dave.Martin, james.morse, tglx,
mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Babu,
On 8/5/25 4:30 PM, Babu Moger wrote:
> 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 CBMs (Capacity Bit Mask) of
> io_alloc feature.
This is a bit vague. How about:
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/). Displaying the resource name is not
> necessary. Pass the resource name to show_doms() and print it only if
"Displaying the resource name is not necessary." -> "Since the
resource name is part of the path it is not necessary to display the
resource name as done in the schemata file."?
> the name is valid. For io_alloc, pass NULL 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 must remain synchronized.
"must remain synchronized" -> "are kept in sync"
> rdtgroup_init_cat() function takes both L3CODE and L3DATA into account when
I do not understand this part. rdtgroup_init_cat() is part of current implementation
and it takes L3CODE and L3DATE of _other_ CLOSID into account when
determining what CBM to initialize new CLOSID with. How is that relevant
here? I wonder if you are not perhaps trying to say:
"resctrl_io_alloc_init_cbm() initializes L3CODE and L3DATA of highest CLOSID
with the same CBM."
I do not think this is necessary to include here though since this is what the
previous patch does and just saying that L3CODE and L3DATA are kept in sync is
sufficient here.
> initializing CBMs for new groups. The io_alloc feature adheres to this
> same principle, meaning that the Cache Bit Masks (CBMs) accessed through
> either L3CODE or L3DATA will reflect identical values.
I do not understand what you are trying to say here. What do you mean with
"same principle"? The fact that L3CODE and L3DATA are kept in sync is
part of io_alloc only, no?
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> ---
...
> ---
...
> +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;
> + }
> +
> + if (!resctrl_arch_get_io_alloc_enabled(r)) {
> + rdt_last_cmd_printf("io_alloc is not enabled on %s\n", s->name);
> + ret = -EINVAL;
> + goto out_unlock;
> + }
> +
Could you please add a comment here that explains to the reader that CBMs of
L3CODE and L3DATA are kept in sync elsewhere and the io_alloc CBMs displayed from
either CDP resource are thus identical and accurately reflect the CBMs used
for I/O.
> + show_doms(seq, s, NULL, resctrl_io_alloc_closid(r));
> +
> +out_unlock:
> + mutex_unlock(&rdtgroup_mutex);
> + cpus_read_unlock();
> + return ret;
> +}
Reinette
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v8 07/10] fs/resctrl: Introduce interface to display io_alloc CBMs
2025-08-08 1:51 ` Reinette Chatre
@ 2025-08-26 18:33 ` Moger, Babu
0 siblings, 0 replies; 34+ messages in thread
From: Moger, Babu @ 2025-08-26 18:33 UTC (permalink / raw)
To: Reinette Chatre, corbet, tony.luck, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Reinette,
On 8/7/25 20:51, Reinette Chatre wrote:
> Hi Babu,
>
> On 8/5/25 4:30 PM, Babu Moger wrote:
>> 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 CBMs (Capacity Bit Mask) of
>> io_alloc feature.
>
> This is a bit vague. How about:
> 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.
Sure.
>>
>> The CBM interface file io_alloc_cbm resides in the info directory
>> (e.g., /sys/fs/resctrl/info/L3/). Displaying the resource name is not
>> necessary. Pass the resource name to show_doms() and print it only if
>
> "Displaying the resource name is not necessary." -> "Since the
> resource name is part of the path it is not necessary to display the
> resource name as done in the schemata file."?
Sure.
>
>
>> the name is valid. For io_alloc, pass NULL 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 must remain synchronized.
>
> "must remain synchronized" -> "are kept in sync"
Sure.
>
>> rdtgroup_init_cat() function takes both L3CODE and L3DATA into account when
>
> I do not understand this part. rdtgroup_init_cat() is part of current implementation
> and it takes L3CODE and L3DATE of _other_ CLOSID into account when
> determining what CBM to initialize new CLOSID with. How is that relevant
> here? I wonder if you are not perhaps trying to say:
> "resctrl_io_alloc_init_cbm() initializes L3CODE and L3DATA of highest CLOSID
> with the same CBM."
> I do not think this is necessary to include here though since this is what the
> previous patch does and just saying that L3CODE and L3DATA are kept in sync is
> sufficient here.
Ok. Sounds good.
>
>> initializing CBMs for new groups. The io_alloc feature adheres to this
>> same principle, meaning that the Cache Bit Masks (CBMs) accessed through
>> either L3CODE or L3DATA will reflect identical values.
>
> I do not understand what you are trying to say here. What do you mean with
> "same principle"? The fact that L3CODE and L3DATA are kept in sync is
> part of io_alloc only, no?
Yes. That is correct. I will remove that text.
>
>>
>> Signed-off-by: Babu Moger <babu.moger@amd.com>
>> ---
>
> ...
>
>> ---
>
> ...
>
>> +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;
>> + }
>> +
>> + if (!resctrl_arch_get_io_alloc_enabled(r)) {
>> + rdt_last_cmd_printf("io_alloc is not enabled on %s\n", s->name);
>> + ret = -EINVAL;
>> + goto out_unlock;
>> + }
>> +
>
> Could you please add a comment here that explains to the reader that CBMs of
> L3CODE and L3DATA are kept in sync elsewhere and the io_alloc CBMs displayed from
> either CDP resource are thus identical and accurately reflect the CBMs used
> for I/O.
Sure.
>
>> + show_doms(seq, s, NULL, resctrl_io_alloc_closid(r));
>> +
>> +out_unlock:
>> + mutex_unlock(&rdtgroup_mutex);
>> + cpus_read_unlock();
>> + return ret;
>> +}
>
> Reinette
>
--
Thanks
Babu Moger
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v8 08/10] fs/resctrl: Modify rdt_parse_data to pass mode and CLOSID
2025-08-05 23:30 [PATCH v8 00/10] x86,fs/resctrl: Support L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE) Babu Moger
` (6 preceding siblings ...)
2025-08-05 23:30 ` [PATCH v8 07/10] fs/resctrl: Introduce interface to display io_alloc CBMs Babu Moger
@ 2025-08-05 23:30 ` Babu Moger
2025-08-08 1:52 ` Reinette Chatre
2025-08-05 23:30 ` [PATCH v8 09/10] fs/resctrl: Introduce interface to modify io_alloc Capacity Bit Masks Babu Moger
2025-08-05 23:30 ` [PATCH v8 10/10] fs/resctrl: Update bit_usage to reflect io_alloc Babu Moger
9 siblings, 1 reply; 34+ messages in thread
From: Babu Moger @ 2025-08-05 23:30 UTC (permalink / raw)
To: corbet, tony.luck, reinette.chatre, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, babu.moger,
yosry.ahmed, sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
parse_cbm() and parse_bw() require 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 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 <babu.moger@amd.com>
---
v8: Rephrase of changelog.
v7: Rephrase of changelog.
v6: Changed the subject line to fs/resctrl.
v5: Resolved conflicts due to recent resctrl FS/ARCH code restructure.
v4: New patch to call parse_cbm() directly to avoid code duplication.
---
fs/resctrl/ctrlmondata.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
index edb9dd131eed..641094aac322 100644
--- a/fs/resctrl/ctrlmondata.c
+++ b/fs/resctrl/ctrlmondata.c
@@ -24,7 +24,8 @@
#include "internal.h"
struct rdt_parse_data {
- struct rdtgroup *rdtgrp;
+ u32 closid;
+ enum rdtgrp_mode mode;
char *buf;
};
@@ -77,8 +78,8 @@ static int parse_bw(struct rdt_parse_data *data, struct resctrl_schema *s,
struct rdt_ctrl_domain *d)
{
struct resctrl_staged_config *cfg;
- u32 closid = data->rdtgrp->closid;
struct rdt_resource *r = s->res;
+ u32 closid = data->closid;
u32 bw_val;
cfg = &d->staged_config[s->conf_type];
@@ -156,9 +157,10 @@ static bool cbm_validate(char *buf, u32 *data, struct rdt_resource *r)
static int parse_cbm(struct rdt_parse_data *data, struct resctrl_schema *s,
struct rdt_ctrl_domain *d)
{
- struct rdtgroup *rdtgrp = data->rdtgrp;
+ enum rdtgrp_mode mode = data->mode;
struct resctrl_staged_config *cfg;
struct rdt_resource *r = s->res;
+ u32 closid = data->closid;
u32 cbm_val;
cfg = &d->staged_config[s->conf_type];
@@ -171,7 +173,7 @@ static int parse_cbm(struct rdt_parse_data *data, struct resctrl_schema *s,
* Cannot set up more than one pseudo-locked region in a cache
* hierarchy.
*/
- if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP &&
+ if (mode == RDT_MODE_PSEUDO_LOCKSETUP &&
rdtgroup_pseudo_locked_in_hierarchy(d)) {
rdt_last_cmd_puts("Pseudo-locked region in hierarchy\n");
return -EINVAL;
@@ -180,8 +182,8 @@ static int parse_cbm(struct rdt_parse_data *data, struct resctrl_schema *s,
if (!cbm_validate(data->buf, &cbm_val, r))
return -EINVAL;
- if ((rdtgrp->mode == RDT_MODE_EXCLUSIVE ||
- rdtgrp->mode == RDT_MODE_SHAREABLE) &&
+ if ((mode == RDT_MODE_EXCLUSIVE ||
+ mode == RDT_MODE_SHAREABLE) &&
rdtgroup_cbm_overlaps_pseudo_locked(d, cbm_val)) {
rdt_last_cmd_puts("CBM overlaps with pseudo-locked region\n");
return -EINVAL;
@@ -191,14 +193,14 @@ static int parse_cbm(struct rdt_parse_data *data, struct resctrl_schema *s,
* The CBM may not overlap with the CBM of another closid if
* either is exclusive.
*/
- if (rdtgroup_cbm_overlaps(s, d, cbm_val, rdtgrp->closid, true)) {
+ if (rdtgroup_cbm_overlaps(s, d, cbm_val, closid, true)) {
rdt_last_cmd_puts("Overlaps with exclusive group\n");
return -EINVAL;
}
- if (rdtgroup_cbm_overlaps(s, d, cbm_val, rdtgrp->closid, false)) {
- if (rdtgrp->mode == RDT_MODE_EXCLUSIVE ||
- rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP) {
+ if (rdtgroup_cbm_overlaps(s, d, cbm_val, closid, false)) {
+ if (mode == RDT_MODE_EXCLUSIVE ||
+ mode == RDT_MODE_PSEUDO_LOCKSETUP) {
rdt_last_cmd_puts("Overlaps with other group\n");
return -EINVAL;
}
@@ -262,7 +264,8 @@ static int parse_line(char *line, struct resctrl_schema *s,
list_for_each_entry(d, &r->ctrl_domains, hdr.list) {
if (d->hdr.id == dom_id) {
data.buf = dom;
- data.rdtgrp = rdtgrp;
+ data.closid = rdtgrp->closid;
+ data.mode = rdtgrp->mode;
if (parse_ctrlval(&data, s, d))
return -EINVAL;
if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP) {
--
2.34.1
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH v8 08/10] fs/resctrl: Modify rdt_parse_data to pass mode and CLOSID
2025-08-05 23:30 ` [PATCH v8 08/10] fs/resctrl: Modify rdt_parse_data to pass mode and CLOSID Babu Moger
@ 2025-08-08 1:52 ` Reinette Chatre
2025-08-26 18:40 ` Moger, Babu
0 siblings, 1 reply; 34+ messages in thread
From: Reinette Chatre @ 2025-08-08 1:52 UTC (permalink / raw)
To: Babu Moger, corbet, tony.luck, Dave.Martin, james.morse, tglx,
mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Babu,
On 8/5/25 4:30 PM, Babu Moger wrote:
> parse_cbm() and parse_bw() require mode and CLOSID to validate the Capacity
Again [1], parse_bw() does not validate any CBMs.
To be more specific: "mode" -> "resource group mode"?
> 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 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 <babu.moger@amd.com>
> ---
...
> @@ -156,9 +157,10 @@ static bool cbm_validate(char *buf, u32 *data, struct rdt_resource *r)
> static int parse_cbm(struct rdt_parse_data *data, struct resctrl_schema *s,
> struct rdt_ctrl_domain *d)
> {
> - struct rdtgroup *rdtgrp = data->rdtgrp;
> + enum rdtgrp_mode mode = data->mode;
> struct resctrl_staged_config *cfg;
> struct rdt_resource *r = s->res;
> + u32 closid = data->closid;
> u32 cbm_val;
>
> cfg = &d->staged_config[s->conf_type];
> @@ -171,7 +173,7 @@ static int parse_cbm(struct rdt_parse_data *data, struct resctrl_schema *s,
> * Cannot set up more than one pseudo-locked region in a cache
> * hierarchy.
> */
> - if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP &&
> + if (mode == RDT_MODE_PSEUDO_LOCKSETUP &&
> rdtgroup_pseudo_locked_in_hierarchy(d)) {
> rdt_last_cmd_puts("Pseudo-locked region in hierarchy\n");
> return -EINVAL;
> @@ -180,8 +182,8 @@ static int parse_cbm(struct rdt_parse_data *data, struct resctrl_schema *s,
> if (!cbm_validate(data->buf, &cbm_val, r))
> return -EINVAL;
>
> - if ((rdtgrp->mode == RDT_MODE_EXCLUSIVE ||
> - rdtgrp->mode == RDT_MODE_SHAREABLE) &&
> + if ((mode == RDT_MODE_EXCLUSIVE ||
> + mode == RDT_MODE_SHAREABLE) &&
This can now be on one line?
> rdtgroup_cbm_overlaps_pseudo_locked(d, cbm_val)) {
> rdt_last_cmd_puts("CBM overlaps with pseudo-locked region\n");
> return -EINVAL;
Reinette
[1] https://lore.kernel.org/lkml/798ba4db-3ac2-44a9-9e0d-e9cbb0dbff45@intel.com/
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v8 08/10] fs/resctrl: Modify rdt_parse_data to pass mode and CLOSID
2025-08-08 1:52 ` Reinette Chatre
@ 2025-08-26 18:40 ` Moger, Babu
0 siblings, 0 replies; 34+ messages in thread
From: Moger, Babu @ 2025-08-26 18:40 UTC (permalink / raw)
To: Reinette Chatre, corbet, tony.luck, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Reinette,
On 8/7/25 20:52, Reinette Chatre wrote:
> Hi Babu,
>
> On 8/5/25 4:30 PM, Babu Moger wrote:
>> parse_cbm() and parse_bw() require mode and CLOSID to validate the Capacity
>
> Again [1], parse_bw() does not validate any CBMs.
Removed parse_bw() reference.
>
> To be more specific: "mode" -> "resource group mode"?
Sure.
>
>> 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 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 <babu.moger@amd.com>
>> ---
>
> ...
>
>> @@ -156,9 +157,10 @@ static bool cbm_validate(char *buf, u32 *data, struct rdt_resource *r)
>> static int parse_cbm(struct rdt_parse_data *data, struct resctrl_schema *s,
>> struct rdt_ctrl_domain *d)
>> {
>> - struct rdtgroup *rdtgrp = data->rdtgrp;
>> + enum rdtgrp_mode mode = data->mode;
>> struct resctrl_staged_config *cfg;
>> struct rdt_resource *r = s->res;
>> + u32 closid = data->closid;
>> u32 cbm_val;
>>
>> cfg = &d->staged_config[s->conf_type];
>> @@ -171,7 +173,7 @@ static int parse_cbm(struct rdt_parse_data *data, struct resctrl_schema *s,
>> * Cannot set up more than one pseudo-locked region in a cache
>> * hierarchy.
>> */
>> - if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP &&
>> + if (mode == RDT_MODE_PSEUDO_LOCKSETUP &&
>> rdtgroup_pseudo_locked_in_hierarchy(d)) {
>> rdt_last_cmd_puts("Pseudo-locked region in hierarchy\n");
>> return -EINVAL;
>> @@ -180,8 +182,8 @@ static int parse_cbm(struct rdt_parse_data *data, struct resctrl_schema *s,
>> if (!cbm_validate(data->buf, &cbm_val, r))
>> return -EINVAL;
>>
>> - if ((rdtgrp->mode == RDT_MODE_EXCLUSIVE ||
>> - rdtgrp->mode == RDT_MODE_SHAREABLE) &&
>> + if ((mode == RDT_MODE_EXCLUSIVE ||
>> + mode == RDT_MODE_SHAREABLE) &&
>
> This can now be on one line?
Sure.
>
>> rdtgroup_cbm_overlaps_pseudo_locked(d, cbm_val)) {
>> rdt_last_cmd_puts("CBM overlaps with pseudo-locked region\n");
>> return -EINVAL;
>
> Reinette
>
> [1] https://lore.kernel.org/lkml/798ba4db-3ac2-44a9-9e0d-e9cbb0dbff45@intel.com/
>
--
Thanks
Babu Moger
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v8 09/10] fs/resctrl: Introduce interface to modify io_alloc Capacity Bit Masks
2025-08-05 23:30 [PATCH v8 00/10] x86,fs/resctrl: Support L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE) Babu Moger
` (7 preceding siblings ...)
2025-08-05 23:30 ` [PATCH v8 08/10] fs/resctrl: Modify rdt_parse_data to pass mode and CLOSID Babu Moger
@ 2025-08-05 23:30 ` Babu Moger
2025-08-08 1:53 ` Reinette Chatre
2025-08-05 23:30 ` [PATCH v8 10/10] fs/resctrl: Update bit_usage to reflect io_alloc Babu Moger
9 siblings, 1 reply; 34+ messages in thread
From: Babu Moger @ 2025-08-05 23:30 UTC (permalink / raw)
To: corbet, tony.luck, reinette.chatre, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, babu.moger,
yosry.ahmed, sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
"io_alloc" feature enables direct insertion of data from I/O devices into
the cache. By directly caching data from I/O devices rather than first
storing the I/O data in DRAM, it reduces the demands on DRAM bandwidth and
reduces latency to the processor consuming the I/O data.
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 must remain synchronized.
rdtgroup_init_cat() function takes both L3CODE and L3DATA into account when
initializing CBMs for new groups. The io_alloc feature must maintain the
same behavior, ensuring that the Cache Bit Masks (CBMs) for both L3CODE and
L3DATA are updated together.
Enable users to modify io_alloc CBMs (Capacity Bit Masks) via the
io_alloc_cbm resctrl file when io_alloc is enabled.
Signed-off-by: Babu Moger <babu.moger@amd.com>
---
v8: Updated changelog.
Moved resctrl_io_alloc_parse_line() and resctrl_io_alloc_cbm_write() to
fs/resctrl/ctrlmondata.c.
Added resctrl_arch_get_cdp_enabled() check inside resctrl_io_alloc_parse_line().
Made parse_cbm() static again as everything moved to ctrlmondata.c.
v7: Updated changelog.
Updated CBMs for both CDP_DATA and CDP_CODE when CDP is enabled.
v6: Updated the user doc restctr.doc for minor texts.
Changed the subject to fs/resctrl.
v5: Changes due to FS/ARCH code restructure. The files monitor.c/rdtgroup.c
have been split between FS and ARCH directories.
Changed the code to access the CBMs via either L3CODE or L3DATA resources.
v4: Removed resctrl_io_alloc_parse_cbm and called parse_cbm() directly.
v3: Minor changes due to changes in resctrl_arch_get_io_alloc_enabled()
and resctrl_io_alloc_closid_get().
Taken care of handling the CBM update when CDP is enabled.
Updated the commit log to make it generic.
v2: Added more generic text in documentation.
---
Documentation/filesystems/resctrl.rst | 8 +++
fs/resctrl/ctrlmondata.c | 97 +++++++++++++++++++++++++++
fs/resctrl/internal.h | 3 +
fs/resctrl/rdtgroup.c | 3 +-
4 files changed, 110 insertions(+), 1 deletion(-)
diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
index 3002f7fdb2fe..d955e8525af0 100644
--- a/Documentation/filesystems/resctrl.rst
+++ b/Documentation/filesystems/resctrl.rst
@@ -187,6 +187,14 @@ related to allocation:
# cat /sys/fs/resctrl/info/L3/io_alloc_cbm
0=ffff;1=ffff
+ 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
+
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
diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
index 641094aac322..1f69117f96f8 100644
--- a/fs/resctrl/ctrlmondata.c
+++ b/fs/resctrl/ctrlmondata.c
@@ -858,3 +858,100 @@ 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 resctrl_schema *peer_s;
+ 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;
+ if (parse_cbm(&data, s, d))
+ return -EINVAL;
+ /*
+ * When CDP is enabled, update the schema for both CDP_DATA
+ * and CDP_CODE.
+ */
+ if (resctrl_arch_get_cdp_enabled(r->rid)) {
+ peer_type = resctrl_peer_type(s->conf_type);
+ peer_s = resctrl_get_schema(peer_type);
+ if (parse_cbm(&data, peer_s, d))
+ return -EINVAL;
+ }
+ 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;
+ }
+
+ rdt_last_cmd_clear();
+ rdt_staged_configs_clear();
+
+ if (!resctrl_arch_get_io_alloc_enabled(r)) {
+ rdt_last_cmd_printf("io_alloc is not enabled on %s\n", s->name);
+ ret = -ENODEV;
+ goto out_unlock;
+ }
+
+ io_alloc_closid = resctrl_io_alloc_closid(r);
+
+ ret = resctrl_io_alloc_parse_line(buf, r, s, io_alloc_closid);
+
+ if (ret)
+ goto out_unlock;
+
+ ret = resctrl_arch_update_domains(r, io_alloc_closid);
+
+out_unlock:
+ rdt_staged_configs_clear();
+ mutex_unlock(&rdtgroup_mutex);
+ cpus_read_unlock();
+
+ return ret ?: nbytes;
+}
diff --git a/fs/resctrl/internal.h b/fs/resctrl/internal.h
index 49934cd3dc40..5467c3ad1b6d 100644
--- a/fs/resctrl/internal.h
+++ b/fs/resctrl/internal.h
@@ -392,6 +392,9 @@ ssize_t resctrl_io_alloc_write(struct kernfs_open_file *of, char *buf,
int resctrl_io_alloc_cbm_show(struct kernfs_open_file *of, struct seq_file *seq,
void *v);
+ssize_t resctrl_io_alloc_cbm_write(struct kernfs_open_file *of, char *buf,
+ size_t nbytes, loff_t off);
+
const char *rdtgroup_name_by_closid(int closid);
#ifdef CONFIG_RESCTRL_FS_PSEUDO_LOCK
diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index 6af8ff6c8385..a3ab2851c6da 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -1919,9 +1919,10 @@ static struct rftype res_common_files[] = {
},
{
.name = "io_alloc_cbm",
- .mode = 0444,
+ .mode = 0644,
.kf_ops = &rdtgroup_kf_single_ops,
.seq_show = resctrl_io_alloc_cbm_show,
+ .write = resctrl_io_alloc_cbm_write,
},
{
.name = "max_threshold_occupancy",
--
2.34.1
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH v8 09/10] fs/resctrl: Introduce interface to modify io_alloc Capacity Bit Masks
2025-08-05 23:30 ` [PATCH v8 09/10] fs/resctrl: Introduce interface to modify io_alloc Capacity Bit Masks Babu Moger
@ 2025-08-08 1:53 ` Reinette Chatre
2025-08-26 18:53 ` Moger, Babu
0 siblings, 1 reply; 34+ messages in thread
From: Reinette Chatre @ 2025-08-08 1:53 UTC (permalink / raw)
To: Babu Moger, corbet, tony.luck, Dave.Martin, james.morse, tglx,
mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Babu,
On 8/5/25 4:30 PM, Babu Moger wrote:
> "io_alloc" feature enables direct insertion of data from I/O devices into
> the cache. By directly caching data from I/O devices rather than first
> storing the I/O data in DRAM, it reduces the demands on DRAM bandwidth and
> reduces latency to the processor consuming the I/O data.
>
> 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 must remain synchronized.
> rdtgroup_init_cat() function takes both L3CODE and L3DATA into account when
> initializing CBMs for new groups. The io_alloc feature must maintain the
> same behavior, ensuring that the Cache Bit Masks (CBMs) for both L3CODE and
> L3DATA are updated together.
Please rework this copy&pasted text also and make specific to what this
patch actually does.
> Enable users to modify io_alloc CBMs (Capacity Bit Masks) via the
> io_alloc_cbm resctrl file when io_alloc is enabled.
Here the changelog can provide overview of what is done by this patch
when a user provides a new CBM. This can include that a CBM provided
to CDP enabled resource will copy the CBM to the CDP peer.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> ---
> ---
> Documentation/filesystems/resctrl.rst | 8 +++
> fs/resctrl/ctrlmondata.c | 97 +++++++++++++++++++++++++++
> fs/resctrl/internal.h | 3 +
> fs/resctrl/rdtgroup.c | 3 +-
> 4 files changed, 110 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
> index 3002f7fdb2fe..d955e8525af0 100644
> --- a/Documentation/filesystems/resctrl.rst
> +++ b/Documentation/filesystems/resctrl.rst
> @@ -187,6 +187,14 @@ related to allocation:
> # cat /sys/fs/resctrl/info/L3/io_alloc_cbm
> 0=ffff;1=ffff
>
> + CBMs can be configured by writing to the interface.
> +
> + Example::
> +
> + # echo 1=FF > /sys/fs/resctrl/info/L3/io_alloc_cbm
It may be useful to demonstrate syntax when more than one CBM is modified.
> + # cat /sys/fs/resctrl/info/L3/io_alloc_cbm
> + 0=ffff;1=00ff
> +
> 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
> diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
> index 641094aac322..1f69117f96f8 100644
> --- a/fs/resctrl/ctrlmondata.c
> +++ b/fs/resctrl/ctrlmondata.c
> @@ -858,3 +858,100 @@ 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 resctrl_schema *peer_s;
> + 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;
> + if (parse_cbm(&data, s, d))
> + return -EINVAL;
> + /*
> + * When CDP is enabled, update the schema for both CDP_DATA
> + * and CDP_CODE.
> + */
> + if (resctrl_arch_get_cdp_enabled(r->rid)) {
> + peer_type = resctrl_peer_type(s->conf_type);
> + peer_s = resctrl_get_schema(peer_type);
> + if (parse_cbm(&data, peer_s, d))
> + return -EINVAL;
CBM is still parsed twice. As I mentioned in v7 the parsing only need to be done
once and then the resulting CBM can be copied to CDP peer.
https://lore.kernel.org/lkml/82045638-2b26-4682-9374-1c3e400a580a@intel.com/
> + }
> + 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;
> + }
> +
> + rdt_last_cmd_clear();
Unnecessary rdt_last_cmd_clear().
> + rdt_staged_configs_clear();
Placement of this can be improved by putting it closer to the code that
populates the staged configs. That is, just before resctrl_io_alloc_parse_line().
The flow is not symmetrical in that the out_unlock exit code always
clears the buffer whether it was used or not. I think it will be easier to
understand if the out_unlock *only* unlocks the locks and there is a new
goto label, for example, "out_clear_configs" that calls rdt_staged_configs_clear()
and is used after resctrl_io_alloc_parse_line().
> +
> + if (!resctrl_arch_get_io_alloc_enabled(r)) {
> + rdt_last_cmd_printf("io_alloc is not enabled on %s\n", s->name);
> + ret = -ENODEV;
> + goto out_unlock;
> + }
> +
> + io_alloc_closid = resctrl_io_alloc_closid(r);
> +
> + ret = resctrl_io_alloc_parse_line(buf, r, s, io_alloc_closid);
> +
> + if (ret)
> + goto out_unlock;
> +
> + ret = resctrl_arch_update_domains(r, io_alloc_closid);
> +
> +out_unlock:
> + rdt_staged_configs_clear();
> + mutex_unlock(&rdtgroup_mutex);
> + cpus_read_unlock();
> +
> + return ret ?: nbytes;
> +}
Reinette
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v8 09/10] fs/resctrl: Introduce interface to modify io_alloc Capacity Bit Masks
2025-08-08 1:53 ` Reinette Chatre
@ 2025-08-26 18:53 ` Moger, Babu
0 siblings, 0 replies; 34+ messages in thread
From: Moger, Babu @ 2025-08-26 18:53 UTC (permalink / raw)
To: Reinette Chatre, corbet, tony.luck, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Reinette,
On 8/7/25 20:53, Reinette Chatre wrote:
> Hi Babu,
>
> On 8/5/25 4:30 PM, Babu Moger wrote:
>> "io_alloc" feature enables direct insertion of data from I/O devices into
>> the cache. By directly caching data from I/O devices rather than first
>> storing the I/O data in DRAM, it reduces the demands on DRAM bandwidth and
>> reduces latency to the processor consuming the I/O data.
>>
>> 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 must remain synchronized.
>> rdtgroup_init_cat() function takes both L3CODE and L3DATA into account when
>> initializing CBMs for new groups. The io_alloc feature must maintain the
>> same behavior, ensuring that the Cache Bit Masks (CBMs) for both L3CODE and
>> L3DATA are updated together.
>
> Please rework this copy&pasted text also and make specific to what this
> patch actually does.
Sure.
>
>> Enable users to modify io_alloc CBMs (Capacity Bit Masks) via the
>> io_alloc_cbm resctrl file when io_alloc is enabled.
>
> Here the changelog can provide overview of what is done by this patch
> when a user provides a new CBM. This can include that a CBM provided
> to CDP enabled resource will copy the CBM to the CDP peer.
Sure.
>
>>
>> Signed-off-by: Babu Moger <babu.moger@amd.com>
>> ---
>
>
>
>> ---
>> Documentation/filesystems/resctrl.rst | 8 +++
>> fs/resctrl/ctrlmondata.c | 97 +++++++++++++++++++++++++++
>> fs/resctrl/internal.h | 3 +
>> fs/resctrl/rdtgroup.c | 3 +-
>> 4 files changed, 110 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
>> index 3002f7fdb2fe..d955e8525af0 100644
>> --- a/Documentation/filesystems/resctrl.rst
>> +++ b/Documentation/filesystems/resctrl.rst
>> @@ -187,6 +187,14 @@ related to allocation:
>> # cat /sys/fs/resctrl/info/L3/io_alloc_cbm
>> 0=ffff;1=ffff
>>
>> + CBMs can be configured by writing to the interface.
>> +
>> + Example::
>> +
>> + # echo 1=FF > /sys/fs/resctrl/info/L3/io_alloc_cbm
>
> It may be useful to demonstrate syntax when more than one CBM is modified.
Sure.
>
>> + # cat /sys/fs/resctrl/info/L3/io_alloc_cbm
>> + 0=ffff;1=00ff
>> +
>> 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
>> diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
>> index 641094aac322..1f69117f96f8 100644
>> --- a/fs/resctrl/ctrlmondata.c
>> +++ b/fs/resctrl/ctrlmondata.c
>> @@ -858,3 +858,100 @@ 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 resctrl_schema *peer_s;
>> + 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;
>> + if (parse_cbm(&data, s, d))
>> + return -EINVAL;
>> + /*
>> + * When CDP is enabled, update the schema for both CDP_DATA
>> + * and CDP_CODE.
>> + */
>> + if (resctrl_arch_get_cdp_enabled(r->rid)) {
>> + peer_type = resctrl_peer_type(s->conf_type);
>> + peer_s = resctrl_get_schema(peer_type);
>> + if (parse_cbm(&data, peer_s, d))
>> + return -EINVAL;
>
> CBM is still parsed twice. As I mentioned in v7 the parsing only need to be done
> once and then the resulting CBM can be copied to CDP peer.
> https://lore.kernel.org/lkml/82045638-2b26-4682-9374-1c3e400a580a@intel.com/
My bad. Simplified now to copy the staged_config from source to its peer.
peer_type = resctrl_peer_type(s->conf_type);
memcpy(&d->staged_config[peer_type],
&d->staged_config[s->conf_type],
sizeof(*d->staged_config));
>
>> + }
>> + 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;
>> + }
>> +
>> + rdt_last_cmd_clear();
>
> Unnecessary rdt_last_cmd_clear().
Removed it.
>
>> + rdt_staged_configs_clear();
>
> Placement of this can be improved by putting it closer to the code that
> populates the staged configs. That is, just before resctrl_io_alloc_parse_line().
> The flow is not symmetrical in that the out_unlock exit code always
> clears the buffer whether it was used or not. I think it will be easier to
> understand if the out_unlock *only* unlocks the locks and there is a new
> goto label, for example, "out_clear_configs" that calls rdt_staged_configs_clear()
> and is used after resctrl_io_alloc_parse_line().
Yes. Sound good.
>
>> +
>> + if (!resctrl_arch_get_io_alloc_enabled(r)) {
>> + rdt_last_cmd_printf("io_alloc is not enabled on %s\n", s->name);
>> + ret = -ENODEV;
>> + goto out_unlock;
>> + }
>> +
>> + io_alloc_closid = resctrl_io_alloc_closid(r);
>> +
>> + ret = resctrl_io_alloc_parse_line(buf, r, s, io_alloc_closid);
>> +
>> + if (ret)
>> + goto out_unlock;
>> +
>> + ret = resctrl_arch_update_domains(r, io_alloc_closid);
>> +
>> +out_unlock:
>> + rdt_staged_configs_clear();
>> + mutex_unlock(&rdtgroup_mutex);
>> + cpus_read_unlock();
>> +
>> + return ret ?: nbytes;
>> +}
>
> Reinette
>
--
Thanks
Babu Moger
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v8 10/10] fs/resctrl: Update bit_usage to reflect io_alloc
2025-08-05 23:30 [PATCH v8 00/10] x86,fs/resctrl: Support L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE) Babu Moger
` (8 preceding siblings ...)
2025-08-05 23:30 ` [PATCH v8 09/10] fs/resctrl: Introduce interface to modify io_alloc Capacity Bit Masks Babu Moger
@ 2025-08-05 23:30 ` Babu Moger
2025-08-08 1:54 ` Reinette Chatre
9 siblings, 1 reply; 34+ messages in thread
From: Babu Moger @ 2025-08-05 23:30 UTC (permalink / raw)
To: corbet, tony.luck, reinette.chatre, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, babu.moger,
yosry.ahmed, sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
When the io_alloc feature is enabled, a portion of the cache can be
configured for shared use between hardware and software.
Update the bit_usage representation to reflect the io_alloc configuration.
Signed-off-by: Babu Moger <babu.moger@amd.com>
---
v8: Moved the patch to last after all the concepts are initialized.
Updated user doc resctrl.rst.
Simplified the CDT check in rdt_bit_usage_show() as CDP_DATA and CDP_CODE
are in sync with io_alloc enabled.
v7: New patch split from earlier patch #5.
Added resctrl_io_alloc_closid() to return max COSID.
---
Documentation/filesystems/resctrl.rst | 19 +++++++++++++------
fs/resctrl/ctrlmondata.c | 2 +-
fs/resctrl/internal.h | 2 ++
fs/resctrl/rdtgroup.c | 18 ++++++++++++++++--
4 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
index d955e8525af0..1e46231b929c 100644
--- a/Documentation/filesystems/resctrl.rst
+++ b/Documentation/filesystems/resctrl.rst
@@ -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.
+
+ 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.
+
"bit_usage":
Annotated capacity bitmasks showing how all
instances of the resource are used. The legend is:
diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
index 1f69117f96f8..cfa766319189 100644
--- a/fs/resctrl/ctrlmondata.c
+++ b/fs/resctrl/ctrlmondata.c
@@ -754,7 +754,7 @@ static int resctrl_io_alloc_init_cbm(struct resctrl_schema *s, u32 closid)
* resource. Note that if Code Data Prioritization (CDP) is enabled, the number
* of available CLOSIDs is reduced by half.
*/
-static u32 resctrl_io_alloc_closid(struct rdt_resource *r)
+u32 resctrl_io_alloc_closid(struct rdt_resource *r)
{
if (resctrl_arch_get_cdp_enabled(r->rid))
return resctrl_arch_get_num_closid(r) / 2 - 1;
diff --git a/fs/resctrl/internal.h b/fs/resctrl/internal.h
index 5467c3ad1b6d..98b87725508b 100644
--- a/fs/resctrl/internal.h
+++ b/fs/resctrl/internal.h
@@ -395,6 +395,8 @@ int resctrl_io_alloc_cbm_show(struct kernfs_open_file *of, struct seq_file *seq,
ssize_t resctrl_io_alloc_cbm_write(struct kernfs_open_file *of, char *buf,
size_t nbytes, loff_t off);
+u32 resctrl_io_alloc_closid(struct rdt_resource *r);
+
const char *rdtgroup_name_by_closid(int closid);
#ifdef CONFIG_RESCTRL_FS_PSEUDO_LOCK
diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index a3ab2851c6da..b85c2622c94b 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -1068,15 +1068,17 @@ static int rdt_bit_usage_show(struct kernfs_open_file *of,
cpus_read_lock();
mutex_lock(&rdtgroup_mutex);
- hw_shareable = r->cache.shareable_bits;
list_for_each_entry(dom, &r->ctrl_domains, hdr.list) {
if (sep)
seq_putc(seq, ';');
+ hw_shareable = r->cache.shareable_bits;
sw_shareable = 0;
exclusive = 0;
seq_printf(seq, "%d=", dom->hdr.id);
for (i = 0; i < closids_supported(); i++) {
- if (!closid_allocated(i))
+ if (!closid_allocated(i) ||
+ (resctrl_arch_get_io_alloc_enabled(r) &&
+ i == resctrl_io_alloc_closid(r)))
continue;
ctrl_val = resctrl_arch_get_config(r, dom, i,
s->conf_type);
@@ -1104,6 +1106,18 @@ static int rdt_bit_usage_show(struct kernfs_open_file *of,
break;
}
}
+
+ /*
+ * When the "io_alloc" feature is enabled, a portion of the
+ * cache is configured for shared use between hardware and software.
+ */
+ if (resctrl_arch_get_io_alloc_enabled(r)) {
+ ctrl_val = resctrl_arch_get_config(r, dom,
+ resctrl_io_alloc_closid(r),
+ s->conf_type);
+ hw_shareable |= ctrl_val;
+ }
+
for (i = r->cache.cbm_len - 1; i >= 0; i--) {
pseudo_locked = dom->plr ? dom->plr->cbm : 0;
hwb = test_bit(i, &hw_shareable);
--
2.34.1
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH v8 10/10] fs/resctrl: Update bit_usage to reflect io_alloc
2025-08-05 23:30 ` [PATCH v8 10/10] fs/resctrl: Update bit_usage to reflect io_alloc Babu Moger
@ 2025-08-08 1:54 ` Reinette Chatre
2025-08-26 22:51 ` Moger, Babu
0 siblings, 1 reply; 34+ messages in thread
From: Reinette Chatre @ 2025-08-08 1:54 UTC (permalink / raw)
To: Babu Moger, corbet, tony.luck, Dave.Martin, james.morse, tglx,
mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Babu
On 8/5/25 4:30 PM, Babu Moger wrote:
> When the io_alloc feature is enabled, a portion of the cache can be
> configured for shared use between hardware and software.
>
> Update the bit_usage representation to reflect the io_alloc configuration.
... but no update to the bit_usage docs :(
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> ---
..
> ---
> Documentation/filesystems/resctrl.rst | 19 +++++++++++++------
> fs/resctrl/ctrlmondata.c | 2 +-
> fs/resctrl/internal.h | 2 ++
> fs/resctrl/rdtgroup.c | 18 ++++++++++++++++--
> 4 files changed, 32 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
> index d955e8525af0..1e46231b929c 100644
> --- a/Documentation/filesystems/resctrl.rst
> +++ b/Documentation/filesystems/resctrl.rst
> @@ -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.
> +
> + 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.
> +
> "bit_usage":
More ignored feedback. I was expecting changes to the "bit_usage" section.
https://lore.kernel.org/lkml/94d075e0-6703-449f-9c0c-8e5973349dff@intel.com/
> Annotated capacity bitmasks showing how all
> instances of the resource are used. The legend is:
> diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
> index 1f69117f96f8..cfa766319189 100644
> --- a/fs/resctrl/ctrlmondata.c
> +++ b/fs/resctrl/ctrlmondata.c
> @@ -754,7 +754,7 @@ static int resctrl_io_alloc_init_cbm(struct resctrl_schema *s, u32 closid)
> * resource. Note that if Code Data Prioritization (CDP) is enabled, the number
> * of available CLOSIDs is reduced by half.
> */
> -static u32 resctrl_io_alloc_closid(struct rdt_resource *r)
> +u32 resctrl_io_alloc_closid(struct rdt_resource *r)
> {
> if (resctrl_arch_get_cdp_enabled(r->rid))
> return resctrl_arch_get_num_closid(r) / 2 - 1;
> diff --git a/fs/resctrl/internal.h b/fs/resctrl/internal.h
> index 5467c3ad1b6d..98b87725508b 100644
> --- a/fs/resctrl/internal.h
> +++ b/fs/resctrl/internal.h
> @@ -395,6 +395,8 @@ int resctrl_io_alloc_cbm_show(struct kernfs_open_file *of, struct seq_file *seq,
> ssize_t resctrl_io_alloc_cbm_write(struct kernfs_open_file *of, char *buf,
> size_t nbytes, loff_t off);
>
> +u32 resctrl_io_alloc_closid(struct rdt_resource *r);
> +
> const char *rdtgroup_name_by_closid(int closid);
>
> #ifdef CONFIG_RESCTRL_FS_PSEUDO_LOCK
> diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
> index a3ab2851c6da..b85c2622c94b 100644
> --- a/fs/resctrl/rdtgroup.c
> +++ b/fs/resctrl/rdtgroup.c
> @@ -1068,15 +1068,17 @@ static int rdt_bit_usage_show(struct kernfs_open_file *of,
>
> cpus_read_lock();
> mutex_lock(&rdtgroup_mutex);
> - hw_shareable = r->cache.shareable_bits;
> list_for_each_entry(dom, &r->ctrl_domains, hdr.list) {
> if (sep)
> seq_putc(seq, ';');
> + hw_shareable = r->cache.shareable_bits;
> sw_shareable = 0;
> exclusive = 0;
> seq_printf(seq, "%d=", dom->hdr.id);
> for (i = 0; i < closids_supported(); i++) {
> - if (!closid_allocated(i))
> + if (!closid_allocated(i) ||
> + (resctrl_arch_get_io_alloc_enabled(r) &&
> + i == resctrl_io_alloc_closid(r)))
> continue;
> ctrl_val = resctrl_arch_get_config(r, dom, i,
> s->conf_type);
> @@ -1104,6 +1106,18 @@ static int rdt_bit_usage_show(struct kernfs_open_file *of,
> break;
> }
> }
> +
> + /*
> + * When the "io_alloc" feature is enabled, a portion of the
> + * cache is configured for shared use between hardware and software.
Please add snippet to comment that highlights that CBM of CDP peers are kept in sync and the
CBM used for I/O can thus be obtained from either.
Reinette
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v8 10/10] fs/resctrl: Update bit_usage to reflect io_alloc
2025-08-08 1:54 ` Reinette Chatre
@ 2025-08-26 22:51 ` Moger, Babu
2025-08-29 3:11 ` Reinette Chatre
0 siblings, 1 reply; 34+ messages in thread
From: Moger, Babu @ 2025-08-26 22:51 UTC (permalink / raw)
To: Reinette Chatre, corbet, tony.luck, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Reinette,
On 8/7/2025 8:54 PM, Reinette Chatre wrote:
> Hi Babu
>
> On 8/5/25 4:30 PM, Babu Moger wrote:
>> When the io_alloc feature is enabled, a portion of the cache can be
>> configured for shared use between hardware and software.
>>
>> Update the bit_usage representation to reflect the io_alloc configuration.
> ... but no update to the bit_usage docs :(
Yes. Missed that. Will update the text.
>
>> Signed-off-by: Babu Moger <babu.moger@amd.com>
>> ---
> ..
>
>> ---
>> Documentation/filesystems/resctrl.rst | 19 +++++++++++++------
>> fs/resctrl/ctrlmondata.c | 2 +-
>> fs/resctrl/internal.h | 2 ++
>> fs/resctrl/rdtgroup.c | 18 ++++++++++++++++--
>> 4 files changed, 32 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
>> index d955e8525af0..1e46231b929c 100644
>> --- a/Documentation/filesystems/resctrl.rst
>> +++ b/Documentation/filesystems/resctrl.rst
>> @@ -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.
>> +
>> + 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.
>> +
>> "bit_usage":
> More ignored feedback. I was expecting changes to the "bit_usage" section.
> https://lore.kernel.org/lkml/94d075e0-6703-449f-9c0c-8e5973349dff@intel.com/
Yea. Added following text now.
diff --git a/Documentation/filesystems/resctrl.rst
b/Documentation/filesystems/resctrl.rst
index 273c9c9389a4..0a56829407c9 100644
--- a/Documentation/filesystems/resctrl.rst
+++ b/Documentation/filesystems/resctrl.rst
@@ -124,8 +124,11 @@ related to allocation:
"X":
Corresponding region is available for
sharing and
used by hardware and software. These are the
- bits that appear in "shareable_bits" as
- well as a resource group's allocation.
+ bits that appear in "shareable_bits" as
well as a
+ resource group's allocation. When io_alloc
is enabled,
+ the capacity bitmasks configured via
io_alloc_cbm will
+ also appear here, indicating the cache
regions shared
+ with I/O devices.
"S":
Corresponding region is used by software
and available for sharing.
>
>> Annotated capacity bitmasks showing how all
>> instances of the resource are used. The legend is:
>> diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
>> index 1f69117f96f8..cfa766319189 100644
>> --- a/fs/resctrl/ctrlmondata.c
>> +++ b/fs/resctrl/ctrlmondata.c
>> @@ -754,7 +754,7 @@ static int resctrl_io_alloc_init_cbm(struct resctrl_schema *s, u32 closid)
>> * resource. Note that if Code Data Prioritization (CDP) is enabled, the number
>> * of available CLOSIDs is reduced by half.
>> */
>> -static u32 resctrl_io_alloc_closid(struct rdt_resource *r)
>> +u32 resctrl_io_alloc_closid(struct rdt_resource *r)
>> {
>> if (resctrl_arch_get_cdp_enabled(r->rid))
>> return resctrl_arch_get_num_closid(r) / 2 - 1;
>> diff --git a/fs/resctrl/internal.h b/fs/resctrl/internal.h
>> index 5467c3ad1b6d..98b87725508b 100644
>> --- a/fs/resctrl/internal.h
>> +++ b/fs/resctrl/internal.h
>> @@ -395,6 +395,8 @@ int resctrl_io_alloc_cbm_show(struct kernfs_open_file *of, struct seq_file *seq,
>> ssize_t resctrl_io_alloc_cbm_write(struct kernfs_open_file *of, char *buf,
>> size_t nbytes, loff_t off);
>>
>> +u32 resctrl_io_alloc_closid(struct rdt_resource *r);
>> +
>> const char *rdtgroup_name_by_closid(int closid);
>>
>> #ifdef CONFIG_RESCTRL_FS_PSEUDO_LOCK
>> diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
>> index a3ab2851c6da..b85c2622c94b 100644
>> --- a/fs/resctrl/rdtgroup.c
>> +++ b/fs/resctrl/rdtgroup.c
>> @@ -1068,15 +1068,17 @@ static int rdt_bit_usage_show(struct kernfs_open_file *of,
>>
>> cpus_read_lock();
>> mutex_lock(&rdtgroup_mutex);
>> - hw_shareable = r->cache.shareable_bits;
>> list_for_each_entry(dom, &r->ctrl_domains, hdr.list) {
>> if (sep)
>> seq_putc(seq, ';');
>> + hw_shareable = r->cache.shareable_bits;
>> sw_shareable = 0;
>> exclusive = 0;
>> seq_printf(seq, "%d=", dom->hdr.id);
>> for (i = 0; i < closids_supported(); i++) {
>> - if (!closid_allocated(i))
>> + if (!closid_allocated(i) ||
>> + (resctrl_arch_get_io_alloc_enabled(r) &&
>> + i == resctrl_io_alloc_closid(r)))
>> continue;
>> ctrl_val = resctrl_arch_get_config(r, dom, i,
>> s->conf_type);
>> @@ -1104,6 +1106,18 @@ static int rdt_bit_usage_show(struct kernfs_open_file *of,
>> break;
>> }
>> }
>> +
>> + /*
>> + * When the "io_alloc" feature is enabled, a portion of the
>> + * cache is configured for shared use between hardware and software.
> Please add snippet to comment that highlights that CBM of CDP peers are kept in sync and the
> CBM used for I/O can thus be obtained from either.
Sure. Thanks
Babu
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH v8 10/10] fs/resctrl: Update bit_usage to reflect io_alloc
2025-08-26 22:51 ` Moger, Babu
@ 2025-08-29 3:11 ` Reinette Chatre
2025-09-02 16:32 ` Moger, Babu
0 siblings, 1 reply; 34+ messages in thread
From: Reinette Chatre @ 2025-08-29 3:11 UTC (permalink / raw)
To: Moger, Babu, corbet, tony.luck, Dave.Martin, james.morse, tglx,
mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Babu,
On 8/26/25 3:51 PM, Moger, Babu wrote:
> Hi Reinette,
>
> On 8/7/2025 8:54 PM, Reinette Chatre wrote:
>> Hi Babu
>>
>> On 8/5/25 4:30 PM, Babu Moger wrote:
>>> When the io_alloc feature is enabled, a portion of the cache can be
>>> configured for shared use between hardware and software.
>>>
>>> Update the bit_usage representation to reflect the io_alloc configuration.
>> ... but no update to the bit_usage docs :(
>
>
> Yes. Missed that. Will update the text.
>
>
>>
>>> Signed-off-by: Babu Moger <babu.moger@amd.com>
>>> ---
>> ..
>>
>>> ---
>>> Documentation/filesystems/resctrl.rst | 19 +++++++++++++------
>>> fs/resctrl/ctrlmondata.c | 2 +-
>>> fs/resctrl/internal.h | 2 ++
>>> fs/resctrl/rdtgroup.c | 18 ++++++++++++++++--
>>> 4 files changed, 32 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
>>> index d955e8525af0..1e46231b929c 100644
>>> --- a/Documentation/filesystems/resctrl.rst
>>> +++ b/Documentation/filesystems/resctrl.rst
>>> @@ -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.
>>> +
>>> + 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.
>>> +
>>> "bit_usage":
>> More ignored feedback. I was expecting changes to the "bit_usage" section.
>> https://lore.kernel.org/lkml/94d075e0-6703-449f-9c0c-8e5973349dff@intel.com/
>
> Yea. Added following text now.
>
>
> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
> index 273c9c9389a4..0a56829407c9 100644
> --- a/Documentation/filesystems/resctrl.rst
> +++ b/Documentation/filesystems/resctrl.rst
> @@ -124,8 +124,11 @@ related to allocation:
> "X":
> Corresponding region is available for sharing and
> used by hardware and software. These are the
> - bits that appear in "shareable_bits" as
> - well as a resource group's allocation.
> + bits that appear in "shareable_bits" as well as a
> + resource group's allocation. When io_alloc is enabled,
> + the capacity bitmasks configured via io_alloc_cbm will
> + also appear here, indicating the cache regions shared
> + with I/O devices.
This sounds as though when a bit is set in io_alloc_cbm then its corresponding position
will contain an "X". An "X" will only be displayed if io_alloc_cbm has the corresponding
bit set *and* the bit appears in a resource group's allocation.
I think that patch #7 adds a very good definition of io_alloc_cbm and that it is
unnecessary to duplicate it. Simply referring to io_alloc_cbm should thus be fine with
user's search for it in the doc leading to a good description.
Considering this, how about just:
"X":
Corresponding region is available for sharing and
used by hardware and software. These are the
bits that appear in "shareable_bits" or "io_alloc_cbm" as
well as a resource group's allocation.
Please also update the "H" section.
Reinette
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v8 10/10] fs/resctrl: Update bit_usage to reflect io_alloc
2025-08-29 3:11 ` Reinette Chatre
@ 2025-09-02 16:32 ` Moger, Babu
0 siblings, 0 replies; 34+ messages in thread
From: Moger, Babu @ 2025-09-02 16:32 UTC (permalink / raw)
To: Reinette Chatre, corbet, tony.luck, Dave.Martin, james.morse,
tglx, mingo, bp, dave.hansen
Cc: x86, hpa, akpm, paulmck, rostedt, Neeraj.Upadhyay, david, arnd,
fvdl, seanjc, thomas.lendacky, pawan.kumar.gupta, yosry.ahmed,
sohil.mehta, xin, kai.huang, xiaoyao.li, peterz, me,
mario.limonciello, xin3.li, ebiggers, ak, chang.seok.bae,
andrew.cooper3, perry.yuan, linux-doc, linux-kernel,
manali.shukla, gautham.shenoy
Hi Reinette,
On 8/28/2025 10:11 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 8/26/25 3:51 PM, Moger, Babu wrote:
>> Hi Reinette,
>>
>> On 8/7/2025 8:54 PM, Reinette Chatre wrote:
>>> Hi Babu
>>>
>>> On 8/5/25 4:30 PM, Babu Moger wrote:
>>>> When the io_alloc feature is enabled, a portion of the cache can be
>>>> configured for shared use between hardware and software.
>>>>
>>>> Update the bit_usage representation to reflect the io_alloc configuration.
>>> ... but no update to the bit_usage docs :(
>>
>> Yes. Missed that. Will update the text.
>>
>>
>>>> Signed-off-by: Babu Moger <babu.moger@amd.com>
>>>> ---
>>> ..
>>>
>>>> ---
>>>> Documentation/filesystems/resctrl.rst | 19 +++++++++++++------
>>>> fs/resctrl/ctrlmondata.c | 2 +-
>>>> fs/resctrl/internal.h | 2 ++
>>>> fs/resctrl/rdtgroup.c | 18 ++++++++++++++++--
>>>> 4 files changed, 32 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
>>>> index d955e8525af0..1e46231b929c 100644
>>>> --- a/Documentation/filesystems/resctrl.rst
>>>> +++ b/Documentation/filesystems/resctrl.rst
>>>> @@ -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.
>>>> +
>>>> + 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.
>>>> +
>>>> "bit_usage":
>>> More ignored feedback. I was expecting changes to the "bit_usage" section.
>>> https://lore.kernel.org/lkml/94d075e0-6703-449f-9c0c-8e5973349dff@intel.com/
>> Yea. Added following text now.
>>
>>
>> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
>> index 273c9c9389a4..0a56829407c9 100644
>> --- a/Documentation/filesystems/resctrl.rst
>> +++ b/Documentation/filesystems/resctrl.rst
>> @@ -124,8 +124,11 @@ related to allocation:
>> "X":
>> Corresponding region is available for sharing and
>> used by hardware and software. These are the
>> - bits that appear in "shareable_bits" as
>> - well as a resource group's allocation.
>> + bits that appear in "shareable_bits" as well as a
>> + resource group's allocation. When io_alloc is enabled,
>> + the capacity bitmasks configured via io_alloc_cbm will
>> + also appear here, indicating the cache regions shared
>> + with I/O devices.
> This sounds as though when a bit is set in io_alloc_cbm then its corresponding position
> will contain an "X". An "X" will only be displayed if io_alloc_cbm has the corresponding
> bit set *and* the bit appears in a resource group's allocation.
>
> I think that patch #7 adds a very good definition of io_alloc_cbm and that it is
> unnecessary to duplicate it. Simply referring to io_alloc_cbm should thus be fine with
> user's search for it in the doc leading to a good description.
>
> Considering this, how about just:
> "X":
> Corresponding region is available for sharing and
> used by hardware and software. These are the
> bits that appear in "shareable_bits" or "io_alloc_cbm" as
> well as a resource group's allocation.
Looks good.
>
>
> Please also update the "H" section.
Sure.
Thanks
Babu
^ permalink raw reply [flat|nested] 34+ messages in thread