Re: [PATCH v2] fs/resctrl: Allocate rmid_ptrs[] using kvzalloc_objs()

[Ben Horgan]

Hi Reinette,

On 16/09/2026 17:52, Reinette Chatre wrote:
> Hi Ben,
> 
> On 9/11/26 9:06 AM, Ben Horgan wrote:
>> On an MPAM system the number of entries in rmid_ptrs[] is the number of PARTIDs
>> multiplied by the number of PMGs. The maximum possible number of PARTIDs is
>> 0x10000 and the maximum number of PMGs is 0x100. On a system pushing the limits
>> of the MPAM specification this can be large enough to consistently fail the
>> kzalloc_objs() allocation and hence fail to mount the resctrl filesystem.
>>
>> Switch to allocating rmid_ptrs[] using kvzalloc_objs() so that large allocations
>> fall back to vmalloc().
>>
>> Fixes: 264c285999fc ("arm_mpam: resctrl: Add monitor initialisation and domain boilerplate")
>> Signed-off-by: Ben Horgan <ben.horgan@xxxxxxx>
>> Reviewed-by: Tony Luck <tony.luck@xxxxxxxxx>
>> ---
>> I found this by testing the extremes of a software model and don't expect this
>> to effect real systems.
>> ---
>>  fs/resctrl/monitor.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c
>> index 73413cb128ea..2d7df60973d1 100644
>> --- a/fs/resctrl/monitor.c
>> +++ b/fs/resctrl/monitor.c
>> @@ -979,7 +979,7 @@ int setup_rmid_lru_list(void)
>>  		return 0;
>>  
>>  	idx_limit = resctrl_arch_system_num_rmid_idx();
>> -	rmid_ptrs = kzalloc_objs(struct rmid_entry, idx_limit);
>> +	rmid_ptrs = kvzalloc_objs(struct rmid_entry, idx_limit);
>>  	if (!rmid_ptrs)
>>  		return -ENOMEM;
>>  
> 
> resctrl_arch_system_num_rmid_idx() that guides the rmid_ptrs[] allocation is
> also used to size the L3 monitoring state rdt_l3_mon_domain::rmid_busy_llc[]
> and rdt_l3_mon_domain::mbm_states[]. Each RMID is expected to have associated
> states in these structures so to fully support this their allocation needs
> to change also? 

At least, rdt_l3_mon_domain::mbm_states[] should use kvcalloc. I realise that I didn't hit this on
the model I was using to test this didn't have memory bandwidth monitors.

For, rdt_l3_mon_domain::rmid_busy_llc[] the allocation will have succeeded on a model as there are
cache occupancy counters. The allocation here is smaller than the others as it allocates a bit per
RMID rather than multiple bytes per RMID like the other two allocations. This gives a limit here of
0x100 * 0x10000 / 0x8 = 0x200000 bytes, 2MB. My view here would be that, although this is quite big,
it's not standing in the way of testing on a model and physical systems even approaching this size
are not likely to ever be built and so doesn't justify either open coding the bitmap allocation and
freeing or creating a new bitmap allocator. Does that make sense?

> I did a quick check and there does not seem to be a
> vmalloc variant for bitmap allocation though so that may need to be
> customized or created.

Yeah, I don't see one either.

Thanks,

Ben>
> Reinette
> 
> 
>