Re: [RFC v2] arm,x86,fs/resctrl: Generic schema description Proof of Concept

[Reinette Chatre]

Hi Babu,

On 8/11/26 7:59 AM, Babu Moger wrote:
> Yes, that's correct. However, when updating the NUMA nodes, we
> cannot call smp_call_function_any(0-7) and
> smp_call_function_any(8-15) as we are currently doing.
> 
> Instead, we need to perform the operation at the L3 cache domain level, for example:
> 
> NUMA0
>   ├─ L3_0: CPUs 0-3   -> smp_call_function_any(0-3)
>   └─ L3_1: CPUs 4-7   -> smp_call_function_any(4-7)
> 
> NUMA1
>   ├─ L3_2: CPUs 8-11  -> smp_call_function_any(8-11)
>   └─ L3_3: CPUs 12-15 -> smp_call_function_any(12-15)
> 
> 
> In other words, the target CPU should be selected from each L3 cache
> group rather than from the entire NUMA node. The current approach
> chooses one CPU from the full NUMA domain, which does not guarantee
> coverage across all L3 cache domains within that NUMA node.

I see. I do not have a clear proposal to deal with this. One (high level) idea to consider
connected to this PoC is possibly changing resctrl_hw_ctrl::msr_update() to be something
more generic. In this version there is a branch where, if resctrl_hw_ctrl::msr_update()
is NULL then it uses a hardcoded program_backing_controls() to program an emulated
control's backing controls instead of the emulated control. These are still at different
scope, msr_update() expects to be called on the CPU needing an update while 
program_backing_controls() will make sure to pick the right CPU(s), but having a generic
callback that can schedule on right CPUs and do updates may provide a way to
help GLBE and emulated controls.

Reinette