On 5/9/2024 5:57 PM, Moger, Babu wrote: > On 5/3/2024 3:44 PM, Moger, Babu wrote: >> On 5/2/2024 7:57 PM, Peter Newman wrote: >>> On Thu, May 2, 2024 at 4:21 PM Reinette Chatre >>> <reinette.chatre@xxxxxxxxx> wrote: >>>> On 5/2/2024 1:14 PM, Moger, Babu wrote: >>>>> Are you suggesting to enable ABMC by default when available? >>>> >>>> I do think ABMC should be enabled by default when available and it looks >>>> to be what this series aims to do [1]. The way I reason about this is >>>> that legacy user space gets more reliable monitoring behavior without >>>> needing to change behavior. >>> >>> I don't like that for a monitor assignment-aware user, following the >>> creation of new monitoring groups, there will be less monitors >>> available for assignment. If the user wants precise control over where >>> monitors are allocated, they would need to manually unassign the >>> automatically-assigned monitor after creating new groups. >>> >>> It's an annoyance, but I'm not sure if it would break any realistic >>> usage model. Maybe if the monitoring agent operates independently of >> >> Yes. Its annoyance. >> >> But if you think about it, normal users don't create too many groups. >> They wont have to worry about assign/unassign headache if we enable monitor assignment automatically. Also there is pqos tool which uses this interface. It does not have to know about assign/unassign stuff. >> >> >>> whoever creates monitoring groups it could result in brief periods >>> where less monitors than expected are available because whoever just >>> created a new monitoring group hasn't given the automatically-assigned >>> monitors back yet. >>> >>>> >>>> I thought there was discussion about communicating to user space >>>> when an attempt is made to read data from an event that does not >>>> have a counter assigned. Something like below but I did not notice this >>>> in this series. >>>> >>>> # cat /sys/fs/resctrl/mon_data/mon_L3_00/mbm_total_bytes >>>> Unassigned >>>> >>>>> >>>>> Then provide the mount option switch back to legacy mode? >>>>> I am fine with that if we all agree on that. >>>> >>>> Why is a mount option needed? I think we should avoid requiring a remount >>>> unless required and I would like to understand why it is required here. >>>> >>>> Peter: could you please elaborate what you mean with it makes it more >>>> difficult for the FS code to generically manage monitor assignment? >>>> >>>> Why would user space be required to recreate all control and monitor >>>> groups if wanting to change how memory bandwidth monitoring is done? >>> >>> I was looking at this more from the perspective of whether it's >>> necessary to support the live transition of the groups' configuration >>> back and forth between programming models. I find it very unlikely >>> for the userspace controller software to change its mind about the >>> programming model for monitoring in a running system, so I thought >>> this would be in the same category as choosing at mount time whether >>> or not to use CDP or the MBA software controller. >> >> Good point about the mount option is, we don't create extra files for monitor assignment in /sys/fs/resctrl when we mount with legacy option. > > I think we still have not decided about the "mount" option for > switching to legacy monitoring. Mount option seems safe at this > point. I have not heard back after sending [1] so I do still believe that users may want a way to not have soft-RMID running all the time without impacting monitor and control groups. > We don't have to deal with extra files in resctrl filesystem > with dynamic switching. Reinette [1] https://lore.kernel.org/lkml/ea56c630-80f4-4564-beb3-2b61e810a558@xxxxxxxxx/
