Re: [PATCH v6 9/9] x86/resctrl: Add MMIO-based LLC occupancy monitoring support

[Reinette Chatre <reinette.chatre@intel.com>]

Hi Chenyu,

On 8/25/26 9:11 AM, Chen, Yu C wrote:
> On 8/20/2026 7:10 AM, Reinette Chatre wrote:
>> On 7/25/26 2:23 AM, 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. This CMRC information is stored in the
>>> rdt_hw_l3_mon_domain, which could be accessed directly.
>>
>> Please write in imperative tone.
>>
> 
> OK, let me try to rewrite it(I suppose you were refereeing to:
> This CMRC information is stored -> Store the CMRC information)

I was, yes.

> 
>>>
>>> Currently, the per-domain limbo handler is still in use. There is no need
>>> to switch to a global limbo handler, because even after such a switch, the
>>> worker thread would still have to iterate through all domains one by one.
>>> The per-domain handler already accomplishes this using a worker thread rather
>>> than costly IPIs, so there is no clear benefit to switching to a global handler.
>>
>> Could you please elaborate how a global limbo handler would require IPIs?
>>
> 
> The global limbo handler does not require IPIs. Previously, I wondered what the
> benefit would be of switching from a per-domain limbo handler to a global one.
> 
> per-domain handler:
> N workers, each worker calculates the current occupancy of that domain
> for a rmid. If the occupancy of all the domains drops below the threshold,
> recycle that rmid. No IPI involved.
> 
> global handler:
> One worker iterates over every domain. If the occupancy of all domains drops
> below the threshold, it recycles the RMID - with no IPI involved.
> 
> For both the per-domain and the global handler, no IPI is involved, and
> we still have to iterate over every domain. So it seems that there is not much
> benefit in switching to the global handler, IIUC.

There is still 1 vs N threads to consider but to me it is also not clear
whether it justifies the complication of supporting two thread models.

> 
>>> diff --git a/arch/x86/include/asm/resctrl.h b/arch/x86/include/asm/resctrl.h
>>> index 5491853113dd..0948f64856ef 100644
>>> --- a/arch/x86/include/asm/resctrl.h
>>> +++ b/arch/x86/include/asm/resctrl.h
>>> @@ -132,7 +132,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;
>>
>> related to earlier topic, "scale" being unsigned int is ok since
>> x86_cache_occ_scale is initialized from 32bits. As I understand it the
>> ERDT scale value is initialized from 64 bits instead so the existing
>> types do not seem to accommodate?
>>
> 
> As you mentioned in another thread, there seems to be an inconsistency
> in the spec, I'll check with the team.
> 
>>>   @@ -39,6 +43,9 @@ static int erdt_scale;
>>>     bool erdt_support(int flag)
>>>   {
>>> +    if (flag == X86_FEATURE_CQM_OCCUP_LLC)
>>> +        return valid_subtbl_mask & BIT(ACPI_ERDT_TYPE_CMRC);
>>> +
>>
>> Is the plan to keep adding more if() statements as new flags need to be tested?
>>
>>
> 
> Yes. For example, to also support MBM:
> 
>      if (flag == X86_FEATURE_CQM_OCCUP_LLC)
>          return valid_subtbl_mask & BIT(ACPI_ERDT_TYPE_CMRC);
> 
>     if (flag == X86_FEATURE_CQM_MBM_TOTAL)
>         return valid_subtbl_mask & BIT(ACPI_ERDT_TYPE_MMRC);
> 

Your example makes it clear that the possible values of @flag are mutually exclusive.
The sequential evaluation as above is not optimal. Every if() needs to be evaluated
until the match is found. I would suggest that this uses switch() instead.

Reinette