Hi Reinette and Babu, On Thu, Aug 1, 2024 at 2:50 PM Reinette Chatre <reinette.chatre@xxxxxxxxx> wrote: > > Hi Babu, > > On 7/17/24 10:19 AM, Moger, Babu wrote: > > Hi Reinette, > > > > On 7/12/24 17:03, Reinette Chatre wrote: > >> Hi Babu, > >> > >> On 7/3/24 2:48 PM, Babu Moger wrote: > >>> # Linux Implementation > >>> > >>> Linux resctrl subsystem provides the interface to count maximum of two > >>> memory bandwidth events per group, from a combination of available total > >>> and local events. Keeping the current interface, users can enable a maximum > >>> of 2 ABMC counters per group. User will also have the option to enable only > >>> one counter to the group. If the system runs out of assignable ABMC > >>> counters, kernel will display an error. Users need to disable an already > >>> enabled counter to make space for new assignments. > >> > >> The implementation appears to be converging on an interface that can > >> be generic enough to be used by other features discussed along the way. > >> "Linux implementation" summary can thus add: > >> > >> Create a generic interface aimed to support user space assignment > >> of scarce counters used for monitoring. First usage of interface > >> is by ABMC with option to expand usage to "soft-RMID" and MPAM > >> counters in future. > > > > Sure. > > > >> > >> > >>> # Examples > >>> > >>> a. Check if ABMC support is available > >>> #mount -t resctrl resctrl /sys/fs/resctrl/ > >>> > >>> #cat /sys/fs/resctrl/info/L3_MON/mbm_mode > >>> [abmc] > >>> legacy > >>> > >>> Linux kernel detected ABMC feature and it is enabled. > >> > >> How about renaming "abmc" to "mbm_cntrs"? This will match the num_mbm_cntrs > >> info file and be the final step to make this generic so that another > >> architecture > >> can more easily support assignining hardware counters without needing to call > >> the feature AMD's "abmc". > > > > I think we aleady settled this with "mbm_cntr_assignable". > > > > For soft-RMID" it will be mbm_sw_assignable. > > Maybe getting a bit long but how about "mbm_cntr_sw_assignable" to match > with the term "mbm_cntr" in accompanying "num_mbm_cntrs"? My users are pushing for a consistent interface regardless of whether counter assignment is implemented in hardware or software, so I would like to avoid exposing implementation differences in the interface where possible. The main semantic difference with SW assignments is that it is not possible to assign counters to individual events. Because the implementation is assigning RMIDs to groups, assignment results in all events being counted. I was considering introducing a boolean mbm_assign_events node to indicate whether assigning individual events is supported. If true, num_mbm_cntrs indicates the number of events which can be counted, otherwise it indicates the number of groups to which counters can be assigned and attempting to assign a single event is silently upgraded to assigning counters to all events in the group. However, If we don't expect to see these semantics in any other implementation, these semantics could be implicit in the definition of a SW assignable counter. -Peter
