Re: [PATCH v5 17/40] x86/resctrl: Rewrite and move the for_each_*_rdt_resource() walkers

From: James Morse
Date: Fri Feb 07 2025 - 10:45:44 EST


Hi Reinette,

On 23/10/2024 22:51, Reinette Chatre wrote:
> On 10/4/24 11:03 AM, James Morse wrote:
>> The for_each_*_rdt_resource() helpers walk the architecture's array
>> of structures, using the resctrl visible part as an iterator. These
>> became over-complex when the structures were split into a
>> filesystem and architecture-specific struct. This approach avoided
>> the need to touch every call site, and was done before there was a
>> helper to retrieve a resource by rid.
>>
>> Once the filesystem parts of resctrl are moved to /fs/, both the
>> architecture's resource array, and the definition of those structures
>> is no longer accessible. To support resctrl, each architecture would
>> have to provide equally complex macros.
>>
>> Rewrite the macro to make use of resctrl_arch_get_resource(), and
>> move these to the core header so existing x86 arch code continues
>> to use them.
>
> The last part is not clear, why does it need to be moved to core
> header for x86 to use it?

If it moves to fs/resctrl/internal.h, this works for the filesystem code, but not x86.
If stays in arch/x86/kernel/cpu/resctrl/internal.h, then the existing filesystem users break.

Moving it to include/linux/resctrl.h means both filesystem and arch code can include it.
I'll add the header file path to the commit message.


>> diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
>> index 8894aed3c593..f75f0409ae09 100644
>> --- a/include/linux/resctrl.h
>> +++ b/include/linux/resctrl.h
>> @@ -26,6 +26,24 @@ int proc_resctrl_show(struct seq_file *m,
>> /* max value for struct rdt_domain's mbps_val */
>> #define MBA_MAX_MBPS U32_MAX
>>
>> +/* Walk all possible resources, with variants for only controls or monitors. */
>> +#define for_each_rdt_resource(_r) \
>> + for ((_r) = resctrl_arch_get_resource(0); \
>> + (_r)->rid < RDT_NUM_RESOURCES - 1; \

> I do not think this reaches all resources ... should this perhaps be:
> (_r) && (_r)->rid < RDT_NUM_RESOURCES

Good catch - I wrongly assumed I was off-by-one when this blew up because the increment is
executed before this expression, and the existing 'RDT_NUM_RESOURCES - 1' reinforced that.
Adding the "(_r) &&" was the correct fix.


Thanks!

James