[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aXpgragcLS2L8ROe@agluck-desk3>
Date: Wed, 28 Jan 2026 11:17:01 -0800
From: "Luck, Tony" <tony.luck@...el.com>
To: "Moger, Babu" <bmoger@....com>
CC: "Moger, Babu" <Babu.Moger@....com>, "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: RE: [RFC PATCH 13/19] x86/resctrl: Add PLZA state tracking and
context switch handling
> > > 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.
Are there other use cases? I think the prime motivation for PLZA is to
avoid priority inversions where some task is running with restricted
resources, and does a system call, or takes an interrupt, and the kernel
is stuck with those limited resources - which may delay context switch
to a high priority process.
That thinking leads to "run all ring 0 code with more resources".
Do you see use cases where you'd like to see the low priority tasks
bumped up to some higher level of resources (but perhaps not full
access). While medium priority tasks keep same resources when entering
ring0.
I think there is some slight oddity if a resctrl group that already
has some tasks is made into the PLZA group.
The existing tasks get marked as PLZA enabled. So run with the same
resources in ring0 and ring3. But you can't add a new task to this
group with that same property. A newly added task retains its ring3
resources by remaining in its original group. It only gets the PLZA
treatment when transitioning to ring0.
-Tony
Powered by blists - more mailing lists