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
| ||
|
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