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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALPaoCi6cd8=Kc6ozDok=s6koxvOH-vTDmaCxbichk_72e6auw@mail.gmail.com>
Date: Mon, 22 Apr 2024 11:39:00 -0700
From: Peter Newman <peternewman@...gle.com>
To: Reinette Chatre <reinette.chatre@...el.com>
Cc: babu.moger@....com, Dave Martin <Dave.Martin@....com>, 
	James Morse <james.morse@....com>, x86@...nel.org, linux-kernel@...r.kernel.org, 
	Fenghua Yu <fenghua.yu@...el.com>, Thomas Gleixner <tglx@...utronix.de>, 
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, H Peter Anvin <hpa@...or.com>, 
	shameerali.kolothum.thodi@...wei.com, 
	D Scott Phillips OS <scott@...amperecomputing.com>, carl@...amperecomputing.com, 
	lcherian@...vell.com, bobo.shaobowang@...wei.com, tan.shaopeng@...itsu.com, 
	baolin.wang@...ux.alibaba.com, Jamie Iles <quic_jiles@...cinc.com>, 
	Xin Hao <xhao@...ux.alibaba.com>, dfustini@...libre.com, amitsinght@...vell.com, 
	David Hildenbrand <david@...hat.com>, Rex Nie <rex.nie@...uarmicro.com>
Subject: Re: [PATCH v1 00/31] x86/resctrl: Move the resctrl filesystem code to /fs/resctrl

Hi Dave,

On Mon, Apr 22, 2024 at 9:01 AM Reinette Chatre
<reinette.chatre@...el.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