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

[Babu Moger <babu.moger@amd.com>]

Hi Reinette,

On 8/11/26 10:30, Reinette Chatre wrote:
> 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.
> 
Yes, the current msr_update implementation is fairly specialized. If we 
refactor it into a more generic handler, each resource can implement its 
own handler, providing greater flexibility and extensibility.

Thanks,
Babu