Re: [PATCH v12 15/25] x86,fs/resctrl: Handle systems where AET is the only resource

[Reinette Chatre]

Hi Tony,

On 9/24/26 5:06 PM, Luck, Tony wrote:
> On Thu, Sep 24, 2026 at 01:41:48PM -0700, Reinette Chatre wrote:
>> On 9/16/26 4:13 PM, Tony Luck wrote:

>>> @@ -1001,27 +1001,29 @@ static __init bool get_rdt_mon_resources(void)
>>>  
>>>  	/* Any of the L3 monitoring features? */
>>>  	if (!cpu_feature_enabled(X86_FEATURE_CQM_LLC))
>>> -		return false;
>>> +		goto skip_l3_feature_checks;
>>
>> This goto looks unnecessary. Why not just "return true"? Even so, this 
>> also changes behavior from the previous version in a way that is not clear
>> to me. I was expecting this to consider the number of RMIDs supported by the system,
>> now that this function added:
>>
>> 	pqr_assoc_num_rmid = cpuid_ebx(0xf) + 1;
>>
>> Should this be:
>>
>> 	if (!cpu_feature_enabled(X86_FEATURE_CQM_LLC))
>> 		return pqr_assoc_num_rmid > 1;
>>
>> Although ... looking at this closer it does look strange for pqr_assoc_num_rmid
>> to be 1, thus reflecting that the system supports one RMID, when zero may be more
>> accurate?
> 
> If X86_FEATURE_CQM_LLC is set, then monitoring is supported and the system
> must support at least one RMID. I don't see a need to insist on more than one
> RMID as a precondition for using resctrl. It wouldn't be super interesting

My suggestion was not to use "more than one RMID as a precondition". By copying the
relevant code not shown in the hunk

	pqr_assoc_num_rmid = cpuid_ebx(0xf) + 1;

I aimed to highlight that if the system returns zero then pqr_assoc_num_rmid
will contain 1. The "pqr_assoc_num_rmid > 1" is thus not a check for "more
than one RMID" but instead a check that the system did not return zero.

> as all activity would be captured by that single RMID.  But it would be
> keeping counts of events.
> 
> So you first instinct above to "just return true" seems reasonable.
> 
Reinette