Received-SPF: pass (google.com: domain of linux-kernel+bounces-153846-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20240321165106.31602-1-james.morse@arm.com> <ed23454e-16df-48e9-a344-a6d8baf902a5@intel.com>
 <ZiE8/oXyjBef2qTy@e133380.arm.com> <acce93e6-4c8e-472d-a2bc-5cbad2950661@intel.com>
 <94c3bfd0-e221-46c7-86c4-f0545e66f17d@amd.com> <4cf859be-294f-4db3-948c-a96b5457a10d@intel.com>
In-Reply-To: <4cf859be-294f-4db3-948c-a96b5457a10d@intel.com>
From: Peter Newman <peternewman@google.com>
Date: Mon, 22 Apr 2024 11:39:00 -0700
Message-ID: <CALPaoCi6cd8=Kc6ozDok=s6koxvOH-vTDmaCxbichk_72e6auw@mail.gmail.com>
Subject: Re: [PATCH v1 00/31] x86/resctrl: Move the resctrl filesystem code to /fs/resctrl
To: Reinette Chatre <reinette.chatre@intel.com>
Cc: babu.moger@amd.com, Dave Martin <Dave.Martin@arm.com>, 
	James Morse <james.morse@arm.com>, x86@kernel.org, linux-kernel@vger.kernel.org, 
	Fenghua Yu <fenghua.yu@intel.com>, Thomas Gleixner <tglx@linutronix.de>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, H Peter Anvin <hpa@zytor.com>, 
	shameerali.kolothum.thodi@huawei.com, 
	D Scott Phillips OS <scott@os.amperecomputing.com>, carl@os.amperecomputing.com, 
	lcherian@marvell.com, bobo.shaobowang@huawei.com, tan.shaopeng@fujitsu.com, 
	baolin.wang@linux.alibaba.com, Jamie Iles <quic_jiles@quicinc.com>, 
	Xin Hao <xhao@linux.alibaba.com>, dfustini@baylibre.com, amitsinght@marvell.com, 
	David Hildenbrand <david@redhat.com>, Rex Nie <rex.nie@jaguarmicro.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Dave,

On Mon, Apr 22, 2024 at 9:01=E2=80=AFAM 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.c=
om/
> >
> > 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 th=
ere
> 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 underst=
and
> 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 someth=
ing
> 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, coul=
d 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