Hi Dave, On 2/21/25 8:47 AM, Dave Martin wrote: > Hi Reinette, > > On Thu, Feb 20, 2025 at 10:36:18AM -0800, Reinette Chatre wrote: >> Hi Dave, >> >> On 2/20/25 9:46 AM, Dave Martin wrote: >>> Hi again, >>> >>> On Thu, Feb 20, 2025 at 04:46:40PM +0000, Dave Martin wrote: > > [...] > >>> Having taken a quick look at that now, this all seems to duplicate >>> perf's design journey (again). >>> >>> "rate" events make some sense. The perf equivalent is to keep an >>> accumulated count of the amount of time a counter has been assigned to >>> an event, and another accumulated count of the events counted by the >>> counter during assignment. Only userspace knows what it wants to do >>> with this information: perf exposes the raw accumulated counts. >>> >>> Perf events can be also pinned so that they are prioritised for >>> assignment to counters; that sounds a lot like the regular, non-shared >>> resctrl counters. >>> >>> >>> Playing devil's advocate: >>> >>> It does feel like we are doomed to reinvent perf if we go too far down >>> this road... >>> >>>> If we split the file, it will be more closely aligned with the design >>>> of the rest of the resctrlfs interface. >>>> >>>> OTOH, the current interface seems workable and I think the file size >>>> issue can be addressed without major re-engineering. >>>> >>>> So, from my side, I would not consider the current interface design >>>> a blocker. >>> >>> ...so, drawing a hard line around the use cases that we intend to >>> address with this interface and avoiding feature creep seems desirable. >> >> This is exactly what I am trying to do ... to understand what use cases >> the interface is expected to support. >> >> You have mentioned a couple of times now that this interface is sufficient but >> at the same time you hinted at some features from MPAM that I do not see >> possible to accommodate with this interface. > > It's kind of both. > > I think the interface is sufficient to be useful, and therefore has > value. > > The problem being addressed here (shortage of counters) is fully > relevant to MPAM (at last on some hardware). > > Any architecture may define new metrics and types of event that can be > counted, and they're not going to match up exactly between arches -- so > I don't think we can expect everything to fit perfectly within a > generic interface. But having a generic interface is still useful for > making common features convenient to use. > > So the interface is useful but not universal, but that doesn't feel > like a bug. > > Hopefully that makes my position a bit clearer. > >>> resctrlfs is already in the wild, so providing reasonable baseline >>> compatiblity with that interface for ABMC hardware is a sensible goal. >>> The current series does that. >>> >>> But I wonder how much additional functionality we should really be >>> adding via the mbm_assign_control interface, once this series is >>> settled. >> >> Are you speculating that MPAM counters may not make use of this interface? >> >> Reinette > > No, I think it makes sense for MPAM to follow this interface, as least > as far as what has been proposed so far here. > > I think James got his updated rebase working. [1] > > > perf support would be for the future if we do it, but the ABMC > interface may be a useful starting point anyway, because it allows > counters to be assigned explicitly -- that provides a natural way to > hand over some counters to perf, either because that interface may be a > more natural fit for what the user is trying to do, or perhaps to count > weird, platform-specific event types that do not merit the effort of > integration into resctrlfs proper. > > Does that make sense? > This is reasonable. You did state earlier that we should aim to draw hard lines around the use cases we aim to address and I think one way this work is doing this is by being explicit in user interface that this is all about "memory bandwidth monitoring". This is not intended to be a fully generic interface for all possible counters for all possible resources. Apart from that time will tell how many blind spots there were while creating this interface. Thank you very much for all your very valuable insights. Reinette
