Re: [PATCH v1 00/31] x86/resctrl: Move the resctrl filesystem code to /fs/resctrl

[Dave Martin]

On Mon, Apr 22, 2024 at 11:39:00AM -0700, Peter Newman wrote:
> Hi Dave,
> 
> On Mon, Apr 22, 2024 at 9:01 AM Reinette Chatre
> <reinette.chatre@xxxxxxxxx> wrote:
> >
> > Hi Babu and Dave,
> >
> > On 4/22/2024 6:51 AM, Moger, Babu wrote:
> > > On 4/19/24 23:06, Reinette Chatre wrote:
> > >>
> > >> [1] https://lore.kernel.org/lkml/cover.1711674410.git.babu.moger@xxxxxxx/
> > >
> > > Do you have any more feedback on this series. I have few feedbacks from
> > > Peter. I was planning to work on v4 of this series.
> > >
> >
> > Babu: It is difficult to start drilling into the implementation before there
> > is agreement on the interface. One reason you went through the effort of
> > the first few iterations was to accommodate Arm's use cases as we understand
> > it, but we need to hear from Arm if we are on the right track here.
> > I do hope that we will hear something in the next couple of weeks.
> >
> > Dave: Could you please check in if the interface introduced [1] is something
> > of interest to Arm? If it is not, we can proceed with the implementation without
> > trying to consider how Arm may use/need such an interface. If it is, could you
> > please let us know when we can expect feedback from Arm?
> 
> Because MPAM implementations typically expose an MSC for each DRAM
> channel, there is an alternate strategy we can use for the monitor
> scalability problem:
> 
> When a single DRAM MSC does not provide enough monitors to track all
> of the supported PARTID x PMG combinations simultaneously, the DRAM
> MSCs collectively may provide a sufficient number of monitors.
> Therefore, as long as the distribution of traffic among the DRAM
> channels is uniform (or predictably non-uniform), it's possible to
> estimate the total bandwidth with sufficient accuracy.
> 
> -Peter
> 

So you're suggesting that if (say) DRAM traffic is striped symmetrically
across N channels, and each has counters, then a counter matching
PARTID:PMG on just one channel should given an unbiased estimate of the
traffic from that group (with some sacrifice of precision, and assuming
the workload is non-pathological)?

I guess that could work, though this might work badly for some workloads
and might give a malicious workload a way to hide transactions from
monitoring if the placement of the counter is too fixed and/or
predictable.

Cheers
---Dave