Re: [RFC v2] arm,x86,fs/resctrl: Generic schema description Proof of Concept
From: Babu Moger
Date: Tue Aug 11 2026 - 13:03:41 EST
Hi Reinette,
On 8/11/26 10:30, Reinette Chatre wrote:
Hi Babu,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.
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.
Thanks,
Babu