Detect SDCIAE`(L3 Smart Data Cache Injection Allocation Enforcement)
feature and initialize sdciae_capable.
Signed-off-by: Babu Moger <babu.moger@amd.com>
---
arch/x86/kernel/cpu/resctrl/core.c | 7 +++++++
include/linux/resctrl.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
index c4dfc768ddf5..e4381e3feb75 100644
--- a/arch/x86/kernel/cpu/resctrl/core.c
+++ b/arch/x86/kernel/cpu/resctrl/core.c
@@ -296,6 +296,11 @@ static void rdt_get_cdp_config(int level)
rdt_resources_all[level].r_resctrl.cdp_capable = true;
}
+static void rdt_get_sdciae_alloc_cfg(struct rdt_resource *r)
+{
+ r->sdciae_capable = true;
+}
+
static void rdt_get_cdp_l3_config(void)
{
rdt_get_cdp_config(RDT_RESOURCE_L3);
@@ -921,6 +926,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_get_sdciae_alloc_cfg(r);
ret = true;
}
if (rdt_cpu_has(X86_FEATURE_CAT_L2)) {
diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
index b0875b99e811..281ba4fb8972 100644
--- a/include/linux/resctrl.h
+++ b/include/linux/resctrl.h
@@ -202,6 +202,7 @@ enum resctrl_scope {
* @evt_list: List of monitoring events
* @fflags: flags to choose base and info files
* @cdp_capable: Is the CDP feature available on this resource
+ * @sdciae_capable: Is SDCIAE feature available on this resource
*/
struct rdt_resource {
int rid;
@@ -224,6 +225,7 @@ struct rdt_resource {
struct list_head evt_list;
unsigned long fflags;
bool cdp_capable;
+ bool sdciae_capable;
};
/**
--
2.34.1Hi Babu, On 8/16/24 9:16 AM, Babu Moger wrote: > Detect SDCIAE`(L3 Smart Data Cache Injection Allocation Enforcement) (stray ` char) > feature and initialize sdciae_capable. (This is a repeat of the discussion we had surrounding the ABMC feature.) By adding "sdciae_capable" to struct rdt_resource the "sdciae" feature becomes a resctrl fs feature. Any other architecture that has a "similar but perhaps not identical feature to AMD's SDCIAE" will be forced to also call it "sdciae" ... sdciae seems like a marketing name to me and resctrl needs something generic that could later be built on (if needed) by other architectures. Reinette
Hi Reinette, On 9/13/24 15:45, Reinette Chatre wrote: > Hi Babu, > > On 8/16/24 9:16 AM, Babu Moger wrote: >> Detect SDCIAE`(L3 Smart Data Cache Injection Allocation Enforcement) > > (stray ` char) Sure. > >> feature and initialize sdciae_capable. > > (This is a repeat of the discussion we had surrounding the ABMC feature.) > > By adding "sdciae_capable" to struct rdt_resource the "sdciae" feature > becomes a resctrl fs feature. Any other architecture that has a "similar > but perhaps not identical feature to AMD's SDCIAE" will be forced to also > call it "sdciae" ... sdciae seems like a marketing name to me and resctrl > needs something generic that could later be built on (if needed) by other > architectures. How about "cache_inject_capable" ? This seems generic. I will change the description also. -- Thanks Babu Moger
On 9/18/24 10:27, Moger, Babu wrote: > Hi Reinette, > > On 9/13/24 15:45, Reinette Chatre wrote: >> Hi Babu, >> >> On 8/16/24 9:16 AM, Babu Moger wrote: >>> Detect SDCIAE`(L3 Smart Data Cache Injection Allocation Enforcement) >> >> (stray ` char) > > Sure. > >> >>> feature and initialize sdciae_capable. >> >> (This is a repeat of the discussion we had surrounding the ABMC feature.) >> >> By adding "sdciae_capable" to struct rdt_resource the "sdciae" feature >> becomes a resctrl fs feature. Any other architecture that has a "similar >> but perhaps not identical feature to AMD's SDCIAE" will be forced to also >> call it "sdciae" ... sdciae seems like a marketing name to me and resctrl >> needs something generic that could later be built on (if needed) by other >> architectures. > > How about "cache_inject_capable" ? > > This seems generic. I will change the description also. > Basically, this feature reserves specific CLOS for SDCI cache. We can also name "clos_reserve_capable". -- Thanks Babu Moger
Hi Babu, On 9/18/24 11:22 AM, Moger, Babu wrote: > > > On 9/18/24 10:27, Moger, Babu wrote: >> Hi Reinette, >> >> On 9/13/24 15:45, Reinette Chatre wrote: >>> Hi Babu, >>> >>> On 8/16/24 9:16 AM, Babu Moger wrote: >>>> Detect SDCIAE`(L3 Smart Data Cache Injection Allocation Enforcement) >>> >>> (stray ` char) >> >> Sure. >> >>> >>>> feature and initialize sdciae_capable. >>> >>> (This is a repeat of the discussion we had surrounding the ABMC feature.) >>> >>> By adding "sdciae_capable" to struct rdt_resource the "sdciae" feature >>> becomes a resctrl fs feature. Any other architecture that has a "similar >>> but perhaps not identical feature to AMD's SDCIAE" will be forced to also >>> call it "sdciae" ... sdciae seems like a marketing name to me and resctrl >>> needs something generic that could later be built on (if needed) by other >>> architectures. >> >> How about "cache_inject_capable" ? >> >> This seems generic. I will change the description also. >> > > Basically, this feature reserves specific CLOS for SDCI cache. > > We can also name "clos_reserve_capable". Naming is always complicated. I think we should try to stay away from "clos" in a generic name since that creates problem when trying to apply it to Arm and is very specific to how AMD implements this feature. "cache_inject_capable" does sound much better to me ... it also looks like this may be more appropriate as a property of struct resctrl_cache? Reinette
Hi Reinette, On 9/19/24 10:33, Reinette Chatre wrote: > Hi Babu, > > On 9/18/24 11:22 AM, Moger, Babu wrote: >> >> >> On 9/18/24 10:27, Moger, Babu wrote: >>> Hi Reinette, >>> >>> On 9/13/24 15:45, Reinette Chatre wrote: >>>> Hi Babu, >>>> >>>> On 8/16/24 9:16 AM, Babu Moger wrote: >>>>> Detect SDCIAE`(L3 Smart Data Cache Injection Allocation Enforcement) >>>> >>>> (stray ` char) >>> >>> Sure. >>> >>>> >>>>> feature and initialize sdciae_capable. >>>> >>>> (This is a repeat of the discussion we had surrounding the ABMC feature.) >>>> >>>> By adding "sdciae_capable" to struct rdt_resource the "sdciae" feature >>>> becomes a resctrl fs feature. Any other architecture that has a "similar >>>> but perhaps not identical feature to AMD's SDCIAE" will be forced to also >>>> call it "sdciae" ... sdciae seems like a marketing name to me and resctrl >>>> needs something generic that could later be built on (if needed) by other >>>> architectures. >>> >>> How about "cache_inject_capable" ? >>> >>> This seems generic. I will change the description also. >>> >> >> Basically, this feature reserves specific CLOS for SDCI cache. >> >> We can also name "clos_reserve_capable". > > Naming is always complicated. I think we should try to stay away from > "clos" in a generic name since that creates problem when trying to > apply it to Arm and is very specific to how AMD implements this > feature. "cache_inject_capable" does sound much better to me ... > it also looks like this may be more appropriate as a property > of struct resctrl_cache? Coming back to this again, I feel 'cache_inject_capable' is kind of very generic. Cache injection term is used very generically everywhere. Does 'cache_reserve_capable" sound good ? This is inside the resctrl subsystem. We know what it is referring to. -- Thanks Babu Moger
Hi Babu, On 10/15/24 1:40 PM, Moger, Babu wrote: > On 9/19/24 10:33, Reinette Chatre wrote: >> On 9/18/24 11:22 AM, Moger, Babu wrote: >>> On 9/18/24 10:27, Moger, Babu wrote: >>>> On 9/13/24 15:45, Reinette Chatre wrote: >>>>> On 8/16/24 9:16 AM, Babu Moger wrote: >>>>>> Detect SDCIAE`(L3 Smart Data Cache Injection Allocation Enforcement) >>>>> >>>>> (stray ` char) >>>> >>>> Sure. >>>> >>>>> >>>>>> feature and initialize sdciae_capable. >>>>> >>>>> (This is a repeat of the discussion we had surrounding the ABMC feature.) >>>>> >>>>> By adding "sdciae_capable" to struct rdt_resource the "sdciae" feature >>>>> becomes a resctrl fs feature. Any other architecture that has a "similar >>>>> but perhaps not identical feature to AMD's SDCIAE" will be forced to also >>>>> call it "sdciae" ... sdciae seems like a marketing name to me and resctrl >>>>> needs something generic that could later be built on (if needed) by other >>>>> architectures. >>>> >>>> How about "cache_inject_capable" ? >>>> >>>> This seems generic. I will change the description also. >>>> >>> >>> Basically, this feature reserves specific CLOS for SDCI cache. >>> >>> We can also name "clos_reserve_capable". >> >> Naming is always complicated. I think we should try to stay away from >> "clos" in a generic name since that creates problem when trying to >> apply it to Arm and is very specific to how AMD implements this >> feature. "cache_inject_capable" does sound much better to me ... >> it also looks like this may be more appropriate as a property >> of struct resctrl_cache? > > Coming back to this again, I feel 'cache_inject_capable' is kind of very > generic. Cache injection term is used very generically everywhere. > > Does 'cache_reserve_capable" sound good ? This is inside the resctrl > subsystem. We know what it is referring to. > Since this is inside resctrl "cache_reserve_capable" sounds like existing CAT to me. Could it help if the term "io" appears in the name? Something like "io_reserve_capable"? When this is a member of struct resctrl_cache it should be implicit that it refers to the cache. Reinette
Hi Reinette, On 10/16/24 10:54, Reinette Chatre wrote: > Hi Babu, > > On 10/15/24 1:40 PM, Moger, Babu wrote: >> On 9/19/24 10:33, Reinette Chatre wrote: >>> On 9/18/24 11:22 AM, Moger, Babu wrote: >>>> On 9/18/24 10:27, Moger, Babu wrote: >>>>> On 9/13/24 15:45, Reinette Chatre wrote: >>>>>> On 8/16/24 9:16 AM, Babu Moger wrote: >>>>>>> Detect SDCIAE`(L3 Smart Data Cache Injection Allocation Enforcement) >>>>>> >>>>>> (stray ` char) >>>>> >>>>> Sure. >>>>> >>>>>> >>>>>>> feature and initialize sdciae_capable. >>>>>> >>>>>> (This is a repeat of the discussion we had surrounding the ABMC feature.) >>>>>> >>>>>> By adding "sdciae_capable" to struct rdt_resource the "sdciae" feature >>>>>> becomes a resctrl fs feature. Any other architecture that has a "similar >>>>>> but perhaps not identical feature to AMD's SDCIAE" will be forced to also >>>>>> call it "sdciae" ... sdciae seems like a marketing name to me and resctrl >>>>>> needs something generic that could later be built on (if needed) by other >>>>>> architectures. >>>>> >>>>> How about "cache_inject_capable" ? >>>>> >>>>> This seems generic. I will change the description also. >>>>> >>>> >>>> Basically, this feature reserves specific CLOS for SDCI cache. >>>> >>>> We can also name "clos_reserve_capable". >>> >>> Naming is always complicated. I think we should try to stay away from >>> "clos" in a generic name since that creates problem when trying to >>> apply it to Arm and is very specific to how AMD implements this >>> feature. "cache_inject_capable" does sound much better to me ... >>> it also looks like this may be more appropriate as a property >>> of struct resctrl_cache? >> >> Coming back to this again, I feel 'cache_inject_capable' is kind of very >> generic. Cache injection term is used very generically everywhere. >> >> Does 'cache_reserve_capable" sound good ? This is inside the resctrl >> subsystem. We know what it is referring to. >> > > Since this is inside resctrl "cache_reserve_capable" sounds like existing > CAT to me. Could it help if the term "io" appears in the name? Something like > "io_reserve_capable"? When this is a member of struct resctrl_cache it should > be implicit that it refers to the cache. Yea. Naming is difficult. How about "io_alloc_capable"? -- Thanks Babu Moger
Hi Babu, On 10/16/24 9:46 AM, Moger, Babu wrote: > On 10/16/24 10:54, Reinette Chatre wrote: >> On 10/15/24 1:40 PM, Moger, Babu wrote: >>> On 9/19/24 10:33, Reinette Chatre wrote: >>>> On 9/18/24 11:22 AM, Moger, Babu wrote: >>>>> On 9/18/24 10:27, Moger, Babu wrote: >>>>>> On 9/13/24 15:45, Reinette Chatre wrote: >>>>>>> On 8/16/24 9:16 AM, Babu Moger wrote: >>>>>>>> Detect SDCIAE`(L3 Smart Data Cache Injection Allocation Enforcement) >>>>>>> >>>>>>> (stray ` char) >>>>>> >>>>>> Sure. >>>>>> >>>>>>> >>>>>>>> feature and initialize sdciae_capable. >>>>>>> >>>>>>> (This is a repeat of the discussion we had surrounding the ABMC feature.) >>>>>>> >>>>>>> By adding "sdciae_capable" to struct rdt_resource the "sdciae" feature >>>>>>> becomes a resctrl fs feature. Any other architecture that has a "similar >>>>>>> but perhaps not identical feature to AMD's SDCIAE" will be forced to also >>>>>>> call it "sdciae" ... sdciae seems like a marketing name to me and resctrl >>>>>>> needs something generic that could later be built on (if needed) by other >>>>>>> architectures. >>>>>> >>>>>> How about "cache_inject_capable" ? >>>>>> >>>>>> This seems generic. I will change the description also. >>>>>> >>>>> >>>>> Basically, this feature reserves specific CLOS for SDCI cache. >>>>> >>>>> We can also name "clos_reserve_capable". >>>> >>>> Naming is always complicated. I think we should try to stay away from >>>> "clos" in a generic name since that creates problem when trying to >>>> apply it to Arm and is very specific to how AMD implements this >>>> feature. "cache_inject_capable" does sound much better to me ... >>>> it also looks like this may be more appropriate as a property >>>> of struct resctrl_cache? >>> >>> Coming back to this again, I feel 'cache_inject_capable' is kind of very >>> generic. Cache injection term is used very generically everywhere. >>> >>> Does 'cache_reserve_capable" sound good ? This is inside the resctrl >>> subsystem. We know what it is referring to. >>> >> >> Since this is inside resctrl "cache_reserve_capable" sounds like existing >> CAT to me. Could it help if the term "io" appears in the name? Something like >> "io_reserve_capable"? When this is a member of struct resctrl_cache it should >> be implicit that it refers to the cache. > > Yea. Naming is difficult. > > How about "io_alloc_capable"? > Sounds good to me, thank you. Reinette
Hi Reinette, On 9/19/2024 10:33 AM, Reinette Chatre wrote: > Hi Babu, > > On 9/18/24 11:22 AM, Moger, Babu wrote: >> >> >> On 9/18/24 10:27, Moger, Babu wrote: >>> Hi Reinette, >>> >>> On 9/13/24 15:45, Reinette Chatre wrote: >>>> Hi Babu, >>>> >>>> On 8/16/24 9:16 AM, Babu Moger wrote: >>>>> Detect SDCIAE`(L3 Smart Data Cache Injection Allocation Enforcement) >>>> >>>> (stray ` char) >>> >>> Sure. >>> >>>> >>>>> feature and initialize sdciae_capable. >>>> >>>> (This is a repeat of the discussion we had surrounding the ABMC feature.) >>>> >>>> By adding "sdciae_capable" to struct rdt_resource the "sdciae" feature >>>> becomes a resctrl fs feature. Any other architecture that has a "similar >>>> but perhaps not identical feature to AMD's SDCIAE" will be forced to also >>>> call it "sdciae" ... sdciae seems like a marketing name to me and resctrl >>>> needs something generic that could later be built on (if needed) by other >>>> architectures. >>> >>> How about "cache_inject_capable" ? >>> >>> This seems generic. I will change the description also. >>> >> >> Basically, this feature reserves specific CLOS for SDCI cache. >> >> We can also name "clos_reserve_capable". > > Naming is always complicated. I think we should try to stay away from > "clos" in a generic name since that creates problem when trying to > apply it to Arm and is very specific to how AMD implements this > feature. "cache_inject_capable" does sound much better to me ... ok, Sure. > it also looks like this may be more appropriate as a property > of struct resctrl_cache? > Yes. Sure. We can do that. -- - Babu Moger
© 2016 - 2026 Red Hat, Inc.