Messages in this thread | | | Date | Tue, 23 Apr 2024 13:37:56 +0100 | From | Dave Martin <> | Subject | Re: [PATCH v1 00/31] x86/resctrl: Move the resctrl filesystem code to /fs/resctrl |
| |
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@intel.com> 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@amd.com/ > > > > > > 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
| |