Hi Babu, On 5/20/25 10:51 AM, Moger, Babu wrote: > Hi Reinette, > > On 5/20/25 11:06, Reinette Chatre wrote: >> Hi Babu, >> >> On 5/20/25 8:28 AM, Moger, Babu wrote: >>> On 5/19/25 10:59, Peter Newman wrote: >>>> On Fri, May 16, 2025 at 12:52 AM Babu Moger <babu.moger@xxxxxxx> wrote: >> >> ... >> >>>>> /sys/fs/resctrl/info/L3_MON/num_mbm_cntrs: Reports the number of monitoring >>>>> counters available for assignment. >>>> >>>> Earlier I discussed with Reinette[1] what num_mbm_cntrs should >>>> represent in a "soft-ABMC" implementation where assignment is >>>> implemented by assigning an RMID, which would result in all events >>>> being assigned at once. >>>> >>>> My main concern is how many "counters" you can assign by assigning >>>> RMIDs. I recall Reinette proposed reporting the number of groups which >>>> can be assigned separately from counters which can be assigned. >>> >>> More context may be needed here. Currently, num_mbm_cntrs indicates the >>> number of counters available per domain, which is 32. >>> >>> At the moment, we can assign 2 counters to each group, meaning each RMID >>> can be associated with 2 hardware counters. In theory, it's possible to >>> assign all 32 hardware counters to a group—allowing one RMID to be linked >>> with up to 32 counters. However, we currently lack the interface to >>> support that level of assignment. >>> >>> For now, the plan is to support basic assignment and expand functionality >>> later once we have the necessary data structure and requirements. >> >> Looks like some requirements did not make it into this implementation. >> Do you recall the discussion that resulted in you writing [2]? Looks like >> there is a question to Peter in there on how to determine how many "counters" >> are available in soft-ABMC. I interpreted [3] at that time to mean that this >> information would be available in a future AMD publication. > > We already have a method to determine the number of counters in soft-ABMC > mode, which Peter has addressed [4]. > > [4] > https://lore.kernel.org/lkml/20250203132642.2746754-1-peternewman@xxxxxxxxxx/ > > This appears to be more of a workaround, and I doubt it will be included > in any official AMD documentation. Additionally, the long-term direction > is moving towards ABMC. > > I don’t believe this workaround needs to be part of the current series. It > can be added later when soft-ABMC is implemented. Agreed. What about the plans described in [2]? (Thanks to Peter for catching this!). It is important to keep track of requirements while working on a feature to ensure that the implementation supports the planned use cases. Re-reading that thread it is not clear to me how soft-ABMC's per-group assignment would look. Could you please share how you see it progress from this implementation? This includes the single event vs. multiple event assignment. I would like to highlight that this is not a request for this to be supported in this implementation but there needs to be a plan for how this can be supported on top of interfaces established by this work. Reinette > >> >> Reinette >> >> [2] https://lore.kernel.org/lkml/afb99efe-0de2-f7ad-d0b8-f2a0ea998efd@xxxxxxx/ >> [3] https://lore.kernel.org/lkml/CALPaoCg3KpF94g2MEmfP_Ro2mQZYFA8sKVkmb+7isotKNgdY9A@xxxxxxxxxxxxxx/ >
