| 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:
<IA0PPF9A76BB3A655A28E9695C8AD1CC59F9591A@IA0PPF9A76BB3A6.namprd12.prod.outlook.com>
Date: Wed, 28 Jan 2026 17:41:24 +0000
From: "Moger, Babu" <Babu.Moger@....com>
To: "Luck, Tony" <tony.luck@...el.com>, "Moger, Babu" <Babu.Moger@....com>
CC: "corbet@....net" <corbet@....net>, "reinette.chatre@...el.com"
<reinette.chatre@...el.com>, "Dave.Martin@....com" <Dave.Martin@....com>,
"james.morse@....com" <james.morse@....com>, "tglx@...nel.org"
<tglx@...nel.org>, "mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de"
<bp@...en8.de>, "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
"peterz@...radead.org" <peterz@...radead.org>, "juri.lelli@...hat.com"
<juri.lelli@...hat.com>, "vincent.guittot@...aro.org"
<vincent.guittot@...aro.org>, "dietmar.eggemann@....com"
<dietmar.eggemann@....com>, "rostedt@...dmis.org" <rostedt@...dmis.org>,
"bsegall@...gle.com" <bsegall@...gle.com>, "mgorman@...e.de"
<mgorman@...e.de>, "vschneid@...hat.com" <vschneid@...hat.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"pawan.kumar.gupta@...ux.intel.com" <pawan.kumar.gupta@...ux.intel.com>,
"pmladek@...e.com" <pmladek@...e.com>, "feng.tang@...ux.alibaba.com"
<feng.tang@...ux.alibaba.com>, "kees@...nel.org" <kees@...nel.org>,
"arnd@...db.de" <arnd@...db.de>, "fvdl@...gle.com" <fvdl@...gle.com>,
"lirongqing@...du.com" <lirongqing@...du.com>, "bhelgaas@...gle.com"
<bhelgaas@...gle.com>, "seanjc@...gle.com" <seanjc@...gle.com>,
"xin@...or.com" <xin@...or.com>, "Shukla, Manali" <Manali.Shukla@....com>,
"dapeng1.mi@...ux.intel.com" <dapeng1.mi@...ux.intel.com>,
"chang.seok.bae@...el.com" <chang.seok.bae@...el.com>, "Limonciello, Mario"
<Mario.Limonciello@....com>, "naveen@...nel.org" <naveen@...nel.org>,
"elena.reshetova@...el.com" <elena.reshetova@...el.com>, "Lendacky, Thomas"
<Thomas.Lendacky@....com>, "linux-doc@...r.kernel.org"
<linux-doc@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"peternewman@...gle.com" <peternewman@...gle.com>, "eranian@...gle.com"
<eranian@...gle.com>, "Shenoy, Gautham Ranjal" <gautham.shenoy@....com>
Subject: RE: [RFC PATCH 13/19] x86/resctrl: Add PLZA state tracking and
context switch handling
[AMD Official Use Only - AMD Internal Distribution Only]
> -----Original Message-----
> From: Luck, Tony <tony.luck@...el.com>
> Sent: Wednesday, January 28, 2026 11:12 AM
> To: Moger, Babu <bmoger@....com>
> Cc: Babu Moger <babu.moger@....com>; corbet@....net;
> reinette.chatre@...el.com; Dave.Martin@....com; james.morse@....com;
> tglx@...nel.org; mingo@...hat.com; bp@...en8.de; dave.hansen@...ux.intel.com;
> x86@...nel.org; hpa@...or.com; peterz@...radead.org; juri.lelli@...hat.com;
> vincent.guittot@...aro.org; dietmar.eggemann@....com; rostedt@...dmis.org;
> bsegall@...gle.com; mgorman@...e.de; vschneid@...hat.com; akpm@...ux-
> foundation.org; pawan.kumar.gupta@...ux.intel.com; pmladek@...e.com;
> feng.tang@...ux.alibaba.com; kees@...nel.org; arnd@...db.de; fvdl@...gle.com;
> lirongqing@...du.com; bhelgaas@...gle.com; seanjc@...gle.com;
> xin@...or.com; manali.shukla@....com; dapeng1.mi@...ux.intel.com;
> chang.seok.bae@...el.com; mario.limonciello@....com; naveen@...nel.org;
> elena.reshetova@...el.com; thomas.lendacky@....com; linux-
> doc@...r.kernel.org; linux-kernel@...r.kernel.org; kvm@...r.kernel.org;
> peternewman@...gle.com; eranian@...gle.com; gautham.shenoy@....com
> Subject: Re: [RFC PATCH 13/19] x86/resctrl: Add PLZA state tracking and context
> switch handling
>
> On Wed, Jan 28, 2026 at 10:01:39AM -0600, Moger, Babu wrote:
> > Hi Tony,
> >
> > Thanks for the comment.
> >
> > On 1/27/2026 4:30 PM, Luck, Tony wrote:
> > > On Wed, Jan 21, 2026 at 03:12:51PM -0600, Babu Moger wrote:
> > > > @@ -138,6 +143,20 @@ static inline void __resctrl_sched_in(struct
> task_struct *tsk)
> > > > state->cur_rmid = rmid;
> > > > wrmsr(MSR_IA32_PQR_ASSOC, rmid, closid);
> > > > }
> > > > +
> > > > + if (static_branch_likely(&rdt_plza_enable_key)) {
> > > > + tmp = READ_ONCE(tsk->plza);
> > > > + if (tmp)
> > > > + plza = tmp;
> > > > +
> > > > + if (plza != state->cur_plza) {
> > > > + state->cur_plza = plza;
> > > > + wrmsr(MSR_IA32_PQR_PLZA_ASSOC,
> > > > + RMID_EN | state->plza_rmid,
> > > > + (plza ? PLZA_EN : 0) | CLOSID_EN | state-
> >plza_closid);
> > > > + }
> > > > + }
> > > > +
> > >
> > > Babu,
> > >
> > > This addition to the context switch code surprised me. After your
> > > talk at LPC I had imagined that PLZA would be a single global
> > > setting so that every syscall/page-fault/interrupt would run with a
> > > different CLOSID (presumably one configured with more cache and memory
> bandwidth).
> > >
> > > But this patch series looks like things are more flexible with the
> > > ability to set different values (of RMID as well as CLOSID) per group.
> >
> > Yes. this similar what we have with MSR_IA32_PQR_ASSOC. The
> > association can be done either thru CPUs (just one MSR write) or task
> > based association(more MSR write as task moves around).
> > >
> > > It looks like it is possible to have some resctrl group with very
> > > limited resources just bump up a bit when in ring0, while other
> > > groups may get some different amount.
> > >
> > > The additions for plza to the Documentation aren't helping me
> > > understand how users will apply this.
> > >
> > > Do you have some more examples?
> >
> > Group creation is similar to what we have currently.
> >
> > 1. create a regular group and setup the limits.
> > # mkdir /sys/fs/resctrl/group
> >
> > 2. Assign tasks or CPUs.
> > # echo 1234 > /sys/fs/resctrl/group/tasks
> >
> > This is a regular group.
> >
> > 3. Now you figured that you need to change things in CPL0 for this task.
> >
> > 4. Now create a PLZA group now and tweek the limits,
> >
> > # mkdir /sys/fs/resctrl/group1
> >
> > # echo 1 > /sys/fs/resctrl/group1/plza
> >
> > # echo "MB:0=100" > /sys/fs/resctrl/group1/schemata
> >
> > 5. Assign the same task to the plza group.
> >
> > # echo 1234 > /sys/fs/resctrl/group1/tasks
> >
> >
> > Now the task 1234 will be using the limits from group1 when running in CPL0.
> >
> > I will add few more details in my next revision.
> >
>
> Babu,
>
> I've read a bit more of the code now and I think I understand more.
>
> Some useful additions to your explanation.
>
> 1) Only one CTRL group can be marked as PLZA
Yes. Correct.
> 2) It can't be the root/default group
This is something I added to keep the default group in a un-disturbed,
> 3) It can't have sub monitor groups
> 4) It can't be pseudo-locked
Yes.
>
> Would a potential use case involve putting *all* tasks into the PLZA group? That
> would avoid any additional context switch overhead as the PLZA MSR would never
> need to change.
Yes. That can be one use case.
>
> If that is the case, maybe for the PLZA group we should allow user to
> do:
>
> # echo '*' > tasks
Yea. It can be done.
Thanks
Babu
Powered by blists - more mailing lists