linux-kernel - Re: [RFC PATCH 13/19] x86/resctrl: Add PLZA state tracking and context switch handling

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: <aXpDdUQHCnQyhcL3@agluck-desk3>
Date: Wed, 28 Jan 2026 09:12:21 -0800
From: "Luck, Tony" <tony.luck@...el.com>
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
2) It can't be the root/default group
3) It can't have sub monitor groups
4) It can't be pseudo-locked

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.

If that is the case, maybe for the PLZA group we should allow user to
do:

# echo '*' > tasks

-Tony