Hi Babu, On Tue, Feb 27, 2024 at 11:37 AM Moger, Babu <babu.moger@xxxxxxx> wrote: > On 2/27/24 12:26, Peter Newman wrote: > > 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. > > We don't need to allocate a h/w counter for unassigned group. > My proposal is to allocate h/w counter only if user requests a assignment. > The limit for assigned events at time is mbm_assignable_counters(32 right > now). I said "RMID", not "counter". The point is, the main purpose served by the RMID in an unassigned mongroup is providing a unique value to write into the task_struct to indicate group membership. > > > > > 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. > > What is soft-ABMC? It's the term I'm using to describe[1] the approach of using the monitor assignment interface to allocate a small number of RMIDs to monitoring groups. -Peter [1] https://lore.kernel.org/lkml/CALPaoCiRD6j_Rp7ffew+PtGTF4rWDORwbuRQqH2i-cY5SvWQBg@xxxxxxxxxxxxxx/
