Re: [PATCH v2 2/2] x86/resctrl: Don't workqueue local event counter reads

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

Hi Tony,

On 11/7/24 8:57 AM, Tony Luck wrote:
> On Thu, Nov 07, 2024 at 03:26:11PM +0100, Peter Newman wrote:
>> On Thu, Nov 7, 2024 at 12:01 PM Peter Newman <peternewman@google.com> wrote:
>>>
>>> Hi Reinette,
>>>
>>> On Thu, Nov 7, 2024 at 2:10 AM Reinette Chatre <reinette.chatre@intel.com> wrote:
>>
>>>> This sounds as though user space is essentially duplicating what the
>>>> MBM overflow handler currently does, which is to run a worker in each domain
>>>> to collect MBM data every second from every RMID for both MBM events.
>>>>
>>>> * What are the requirements of this use case?
>>>
>>> Accurate, per-RMID MBps data, ideally at 1-second resolution if the
>>> overhead can be tolerable.
>>
>> Sorry, forgot about the assignable counters issue...
>>
>> On AMD we'll have to cycle the available event counters through the
>> groups in order to get valid bandwidth counts.
> 
> See below.
> 
>>>> For example,
>>>>         # cat /sys/fs/resctrl/info/L3_MON/mbm_snapshot/mbm_total_bytes_00
>>>>           <rdtgroup nameA> <MBM total count>
>>>>           <rdtgroup nameB> <MBM total count>
>>>>           ...
>>>>
>>>>         # cat /sys/fs/resctrl/info/L3_MON/mbm_snapshot/mbm_total_bytes_01
>>>>           <rdtgroup nameA> <MBM total count>
>>>>           <rdtgroup nameB> <MBM total count>
>>>>           ...
> 
> How about:
> 
> # cat /sys/fs/resctrl/info/L3_MON/mbm_snapshot/mbm_total_bytes_00
> <rdtgroup nameA> <MBM total count> <timestamp> <generation>
> <rdtgroup nameB> <MBM total count> <timestamp> <generation>
> ...
>>>>
> # cat /sys/fs/resctrl/info/L3_MON/mbm_snapshot/mbm_total_bytes_01
> <rdtgroup nameA> <MBM total count> <timestamp> <generation>
> <rdtgroup nameB> <MBM total count> <timestamp> <generation>
> ...
> 
> Where <timestamp> tracks when this sample was captured. And
> <generation> is an integer that is incremented when data
> for this event is lost (e.g. due to ABMC counter re-assignment).

It is not obvious to me how resctrl can provide a reliable
"generation" value.

 
> Then a monitor application can compute bandwidth for each
> group by periodic sampling and for each group:
> 
> 	if (thisgeneration == lastgeneration) {
> 		bw = (thiscount - lastcount) / (thistimestanp - lasttimestamp);

If user space needs visibility into these internals then we could also
consider adding a trace event that logs the timestamped data right when it
is queried by the overflow handler.

Reinette