Re: [PATCH v8 9/9] x86/resctrl: Add MMIO-based LLC occupancy monitoring support
From: Reinette Chatre
Date: Mon Sep 28 2026 - 17:57:10 EST
Hi Chenyu,
On 9/17/26 9:51 PM, Chen Yu wrote:
> Add erdt_mon_read() to read LLC occupancy via MMIO and use it when the platform
> supports ERDT. Register the L3 occupancy event with ERDT enabled when available,
> falling back to the MSR-based path otherwise.
>
> Use the CMRC (Cache Monitoring Registers for CPU Agents Description) ACPI
> sub-table to read LLC occupancy counters for each RMID via MMIO when ERDT is
> enabled. Store the CMRC information in the rdt_hw_l3_mon_domain, which could be
> accessed directly.
Regarding "Store the CMRC ..." - wasn't that done in patch #5?
>
> Although the occupancy counters can now be read from any CPU via MMIO, the
> per-domain limbo handler is kept. A global handler would still have to iterate
"per-domain limbo handler is kept" - needs imperative
> over every domain and would only save one worker thread, which does not justify
"would only save one worker thread"? this assumes that all systems will have two domains?
> maintaining two limbo handler models.
>
> Suggested-by: Reinette Chatre <reinette.chatre@xxxxxxxxx>
> Signed-off-by: Chen Yu <yu.c.chen@xxxxxxxxx>
> Tested-by: Hongyu Ning <hongyu.ning@xxxxxxxxxxxxxxx>
> ---
> arch/x86/include/asm/resctrl.h | 8 ++-
> arch/x86/kernel/cpu/resctrl/core.c | 5 +-
> arch/x86/kernel/cpu/resctrl/erdt.c | 74 +++++++++++++++++++++++++-
> arch/x86/kernel/cpu/resctrl/internal.h | 9 +++-
> arch/x86/kernel/cpu/resctrl/monitor.c | 14 +++--
> 5 files changed, 102 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/include/asm/resctrl.h b/arch/x86/include/asm/resctrl.h
> index bcfcc8ac1fe6..31c2f81cd06e 100644
> --- a/arch/x86/include/asm/resctrl.h
> +++ b/arch/x86/include/asm/resctrl.h
> @@ -135,7 +135,13 @@ static inline void __resctrl_sched_in(struct task_struct *tsk)
>
> static inline unsigned int resctrl_arch_round_mon_val(unsigned int val)
> {
> - unsigned int scale = boot_cpu_data.x86_cache_occ_scale;
> + unsigned int scale = boot_cpu_data.x86_cache_occ_scale, escale;
> +
> + if (erdt_cpu_has(X86_FEATURE_CQM_OCCUP_LLC)) {
> + escale = erdt_get_scale();
> + if (escale)
> + scale = escale;
> + }
>
> /* h/w works in units of "boot_cpu_data.x86_cache_occ_scale" */
This comment is no longer accurate.
> val /= scale;
> diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
> index ca7e67f976d5..135f2eb2a5a5 100644
> --- a/arch/x86/kernel/cpu/resctrl/core.c
> +++ b/arch/x86/kernel/cpu/resctrl/core.c
> @@ -1007,7 +1007,10 @@ static __init bool get_rdt_mon_resources(void)
> struct rdt_resource *r = &rdt_resources_all[RDT_RESOURCE_L3].r_resctrl;
> bool ret = false;
>
> - if (rdt_cpu_has(X86_FEATURE_CQM_OCCUP_LLC)) {
> + if (erdt_cpu_has(X86_FEATURE_CQM_OCCUP_LLC)) {
> + resctrl_enable_mon_event(QOS_L3_OCCUP_EVENT_ID, true, 0, NULL);
> + ret = true;
> + } else if (rdt_cpu_has(X86_FEATURE_CQM_OCCUP_LLC)) {
> resctrl_enable_mon_event(QOS_L3_OCCUP_EVENT_ID, false, 0, NULL);
> ret = true;
> }
Would https://lore.kernel.org/lkml/20260916231320.14502-3-tony.luck@xxxxxxxxx/
break this?
> diff --git a/arch/x86/kernel/cpu/resctrl/erdt.c b/arch/x86/kernel/cpu/resctrl/erdt.c
> index 400973ebf2b8..f350a516d3d9 100644
> --- a/arch/x86/kernel/cpu/resctrl/erdt.c
> +++ b/arch/x86/kernel/cpu/resctrl/erdt.c
> @@ -26,6 +26,10 @@ static bool erdt_enabled;
> #define CMRC_SUPPORTED_INDEX_FN 1
> #define RMDD_FLAG_CPU_L3_DOMAIN BIT(0)
>
> +/* Set in a monitoring counter when it holds no valid data to report. */
> +#define UNAVAILABLE_COUNTER BIT_ULL(63)
Can this be CMRC_UNAVAILABLE_COUNTER? (or some other appropriate prefix that makes
it more specific)
> +#define CMRC_FLAG_UNAVAILABLE_BIT BIT(0)
> +
> /* Bitmask of valid sub-tables found in the first RMDD, used to ensure all RMDDs match. */
> static u32 valid_subtbl_mask;
>
> @@ -50,7 +54,12 @@ static unsigned int erdt_scale;
>
> bool erdt_support(int flag)
> {
> - return false;
> + switch (flag) {
> + case X86_FEATURE_CQM_OCCUP_LLC:
> + return valid_subtbl_mask & BIT(ACPI_ERDT_TYPE_CMRC);
> + default:
> + return false;
> + }
> }
>
> unsigned int erdt_get_max_rmid(void)
> @@ -60,7 +69,68 @@ unsigned int erdt_get_max_rmid(void)
>
> unsigned int erdt_get_scale(void)
> {
> - return erdt_scale;
> + /* Divided by snc_nodes_per_l3_cache, see erdt_read_l3_occupancy(). */
> + return erdt_scale / snc_nodes_per_l3_cache;
> +}
> +
> +static u32 cmrc_index_function_1(struct acpi_erdt_cmrc *cmrc, u32 rmid)
Please add a function comment connecting cmrc_index_function_1() to CMRC_SUPPORTED_INDEX_FN
and also documents where this function comes from (eg. RDT architecture spec).
> +{
> + /*
> + * MMIO_offset_for_RMID# =
> + * (RMID / ClumpSize) * Stride +
> + * (RMID % ClumpSize) * 8
Looks like above can just be on one line? When adding function comment about origin of
algorithm it may be more fitting to move this comment there.
> + */
> + return (rmid / cmrc->clump_size) * cmrc->clump_stride +
> + (rmid % cmrc->clump_size) * 8;
> +}
> +
> +static int erdt_read_l3_occupancy(const struct erdt_domain_info *d, u32 rmid, u64 *val)
> +{
> + struct acpi_erdt_cmrc *cmrc;
> + u64 l3_cmt_count;
> + u32 offset;
> +
> + cmrc = d->cmrc;
> + if (!cmrc)
> + return -EIO;
> +
> + offset = cmrc_index_function_1(cmrc, rmid);
> + /* Overflow of cmt_reg_size * SZ_4K already validated in erdt_ioremap(). */
> + if (offset + sizeof(u64) > (u32)cmrc->cmt_reg_size * SZ_4K)
> + return -EINVAL;
> +
> + l3_cmt_count = readq(d->base[ERDT_MMIO_CMRC_BASE] + offset);
> + if ((cmrc->flags & CMRC_FLAG_UNAVAILABLE_BIT) &&
> + (l3_cmt_count & UNAVAILABLE_COUNTER))
> + return -EINVAL;
> +
> + /*
> + * In legacy mode, scale is divided by snc_nodes_per_l3_cache to
> + * prevent over-calculation of aggregated monitor data, do it
> + * the same for MMIO based access.
> + * This scaling factor might need to be revisited/tuned for future
> + * platforms that support both SNC and MMIO-based monitoring
> + * simultaneously.
> + */
> + *val = l3_cmt_count * cmrc->up_scale / snc_nodes_per_l3_cache;
Please consider all sashiko's comments about SNC systems - from what I can tell
the comments are accurate and the SNC support needs a second look.
Reinette