Re: [PATCH v4 00/19] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC)

[Reinette Chatre <reinette.chatre@intel.com>]

Hi Babu,

On 6/18/24 2:02 PM, Moger, Babu wrote:
> On 6/13/24 19:54, Reinette Chatre wrote:
>> On 5/24/24 5:23 AM, Babu Moger wrote:
>>
>>>     when reading, then the read will come back as Unavailable.
>>
>> Should this not rather be "Unassigned"? According to the docs the counters
>> will return "Unavailable" right after reconfigure so it seems that there
>> are scenarios where an "assigned" counter returns "Unavailable". It seems
>> more
>> useful to return "Unassigned" that will have a new specific meaning that
>> overloading existing "Unavailable" that has original meaning of "try
>> again" ....
>> but in this case trying again will be futile.
> 
> Hardware returns "Unavailable" in both the cases. So, thought of reporting the same without any interpretation.
> 

I do not see these as the same. When a counter is assigned and its
read returns "Unavailable" then the user reasonably expects that
retry will work.
When a counter is not assigned then no amount of retries will result
in data. How is user space expected to distinguish between the two
scenarios that return the same error with such significantly different
meaning? rdtgroup_mondata_shows() can just peek into the monitor
group state and see if a counter is assigned and immediately
return "Unassigned" if no counter is assigned, no? I see no need
for it to IPI another CPU and try to read a counter that it already knows
will be futile. This seems unnecessary and the generic "Unavailable" is
not helpful to user space.

Reinette