Hi Babu, On Tue, Feb 27, 2024 at 10:12 AM Moger, Babu <babu.moger@xxxxxxx> wrote: > > On 2/26/24 15:20, Reinette Chatre wrote: > > > > For example, if I understand correctly, theoretically, when ABMC is enabled then > > "num_rmids" can be U32_MAX (after a quick look it is not clear to me why r->num_rmid > > is not unsigned, tbd if number of directories may also be limited by kernfs). > > User space could theoretically create more monitor groups than the number of > > rmids that a resource claims to support using current upstream enumeration. > > CPU or task association still uses PQR_ASSOC(MSR C8Fh). There are only 11 > bits(depends on specific h/w) to represent RMIDs. So, we cannot create > more than this limit(r->num_rmid). > > In case of ABMC, h/w uses another counter(mbm_assignable_counters) with > RMID to assign the monitoring. So, assignment limit is > mbm_assignable_counters. The number of mon groups limit is still r->num_rmid. That is not entirely true. As long as you don't need to maintain bandwidth counts for unassigned monitoring groups, there's no need to allocate a HW RMID to a monitoring group. In my soft-ABMC prototype, where a limited number of HW RMIDs are allocated to assigned monitoring groups, I was forced to replace the HW RMID value stored in the task_struct to a pointer to the struct mongroup, since the RMID value assigned to the mongroup would frequently change, resulting in excessive walks down the tasklist to find all of the tasks using the previous value. However, the number of hardware monitor group identifiers supported (i.e., RMID, PARTID:PMG) is usually high enough that I don't think there's much motivation to support unlimited monitoring groups. In both soft-RMID and soft-ABMC, I didn't bother supporting more groups than num_rmids, because the number was large enough. -Peter
