[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALPaoCiFotg80LJZ3d+QeO=bNUh85AuP2VgmLaWXX7JaAMYfLQ@mail.gmail.com>
Date: Fri, 27 Jan 2023 17:02:15 +0100
From: Peter Newman <peternewman@...gle.com>
To: "Yu, Fenghua" <fenghua.yu@...el.com>
Cc: "Luck, Tony" <tony.luck@...el.com>,
"Chatre, Reinette" <reinette.chatre@...el.com>,
Jonathan Corbet <corbet@....net>,
"x86@...nel.org" <x86@...nel.org>,
Shaopeng Tan <tan.shaopeng@...itsu.com>,
James Morse <james.morse@....com>,
Jamie Iles <quic_jiles@...cinc.com>,
Babu Moger <babu.moger@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"patches@...ts.linux.dev" <patches@...ts.linux.dev>
Subject: Re: [PATCH 3/7] x86/resctrl: Add a new node-scoped resource to rdt_resources_all[]
Hi Tony,
On Fri, Jan 27, 2023 at 6:25 AM Yu, Fenghua <fenghua.yu@...el.com> wrote:
>
> On 1/26/23 10:41, Tony Luck wrote:
> > diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
> > index 6914232acf84..19be6fe42ef3 100644
> > --- a/arch/x86/kernel/cpu/resctrl/core.c
> > +++ b/arch/x86/kernel/cpu/resctrl/core.c
> > @@ -100,6 +100,16 @@ struct rdt_hw_resource rdt_resources_all[] = {
> > .fflags = RFTYPE_RES_MB,
> > },
> > },
> > + [RDT_RESOURCE_NODE] =
> > + {
> > + .r_resctrl = {
> > + .rid = RDT_RESOURCE_NODE,
> > + .name = "L3",
> "L3" was named as RDT_RESOURCE_L3 already. The duplicate name here may
> cause duplicate file names in info dir. Maybe rename it as "L3_NODE"?
I'm trying to get some feedback from our own users on whether changing
the directory names would bother them. At least from my own testing, I
did learn to appreciate the interface change a bit more: I needed an
SNC and non-SNC case to correctly predict which mon_data subdirectory
the data would appear in.
I was able to confirm that this change allows bandwidth to be counted
on RMID/CPU combos where it didn't work before on an SNC2
configuration.
If I'm understanding this correctly, it might be helpful to highlight
that the extra resource is needed to allow a different number of L3
domains in L3 monitoring vs allocation.
Thanks!
-Peter
Tested-By: Peter Newman <peternewman@...gle.com>
Reviewed-By: Peter Newman <peternewman@...gle.com>
Powered by blists - more mailing lists