From: Babu Moger <babu.moger@amd.com>
To: Reinette Chatre <reinette.chatre@intel.com>,
tony.luck@intel.com, Dave.Martin@arm.com, james.morse@arm.com,
bp@alien8.de, ben.horgan@arm.com
Cc: corbet@lwn.net, skhan@linuxfoundation.org, rdunlap@infradead.org,
tglx@kernel.org, mingo@redhat.com, dave.hansen@linux.intel.com,
hpa@zytor.com, fenghuay@nvidia.com, akpm@linux-foundation.org,
rppt@kernel.org, dapeng1.mi@linux.intel.com, elver@google.com,
jlayton@kernel.org, enelsonmoore@gmail.com, kuba@kernel.org,
ebiggers@kernel.org, seanjc@google.com, peterz@infradead.org,
chao.gao@intel.com, jmattson@google.com, naveen@kernel.org,
ricardo.neri-calderon@linux.intel.com, tiala@microsoft.com,
chang.seok.bae@intel.com, prathyushi.nangia@amd.com,
kim.phillips@amd.com, elena.reshetova@intel.com,
darwi@linutronix.de, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH v5 01/16] x86/cpufeatures: Support Privilege Level Zero Association (PLZA)
Date: Thu, 17 Sep 2026 12:08:21 -0500 [thread overview]
Message-ID: <ae54323b-d687-4340-9134-f8eb9fad859e@amd.com> (raw)
In-Reply-To: <75120223-ed93-478d-924a-12507a1fb3c6@intel.com>
Hi Reinette,
On 9/17/26 10:04, Reinette Chatre wrote:
> Hi Babu,
>
> On 9/16/26 1:45 PM, Babu Moger wrote:
>> On 9/16/26 00:12, Reinette Chatre wrote:
>>> On 8/26/26 12:32 PM, Babu Moger wrote:
>
>
> ...
>
>>
>>>
>>>>
>>>> PLZA also applies to cache allocation and monitoring features and provides
>>>> flexibility to manage allocation and monitoring associations independently.
>>>
>>> This reads like an afterthought. Are users expected to use cache allocation
>>> while PLZA is enabled? Since only one resource group can be assigned I expect
>>> there to be quite a few sharp corners when both are in use. Kernel work done
>>> on behalf of high as well as low priority work will use the same cache allocations
>>> and thus neither could actually get full benefit from having dedicated cache
>>> portions?
>>
>> The best-known use case today is to leave both cache allocation and
>> memory bandwidth allocation at their default (maximum) settings and
>> enable PLZA on all CPUs.
>
> Interesting. This sounds like all kernel work can access the entire cache
> and thus evict data from any user space tasks that may have used cache allocation
> to avoid interference.
>
>>
>> Users can, however, configure both cache allocation and memory bandwidth limits. In those cases, there can be corner-case behaviors and trade-offs.
>>
>> If you think the current wording is misleading, I can drop that text and rephrase it along these lines to include both cache and memory.
>
> No, the wording is not misleading. The description just focuses on memory bandwidth
> allocation leaving impression that the feature only applies to that resource when it
> applies to all resources.
>
>>
>> "When cache and/or memory bandwidth associated with a CLOSID is
>> aggressively throttled, and a task with that CLOSID moves into
>> kernel mode, the kernel operations are also aggressively throttled.
>> This can stall forward progress and eventually degrade overall
>> system performance.
>>
>> AMD hardware supports the Privilege Level Zero Association (PLZA)
>> feature, which allows the CPU's CLOSID and/or RMID association to be
>> changed during transitions from user mode to kernel mode. This
>> enables the kernel to run with a different CLOSID and/or RMID than
>> user space, improving system performance and/or allowing kernel work
>> to be monitored separately.">
>
> I think what you have for memory bandwidth sounds good. I do not think
> the cache allocation and memory bandwidth usage descriptions should be
> mixed since the implications are so different. Could you please just
> add a snippet that highlights since the feature assigns CLOSID/RMID to
> kernel work it influences allocation and monitoring of all resources,
> not just memory bandwidth?
>
Yes. Sure.
Thanks
Babu
next prev parent reply other threads:[~2026-09-17 17:09 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 19:32 [PATCH v5 00/16] x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem Babu Moger
2026-08-26 19:32 ` [PATCH v5 01/16] x86/cpufeatures: Support Privilege Level Zero Association (PLZA) Babu Moger
2026-09-16 5:12 ` Reinette Chatre
2026-09-16 20:45 ` Babu Moger
2026-09-17 15:04 ` Reinette Chatre
2026-09-17 17:08 ` Babu Moger [this message]
2026-08-26 19:32 ` [PATCH v5 02/16] x86/resctrl: Add PLZA support to command-line options Babu Moger
2026-09-16 5:12 ` Reinette Chatre
2026-09-16 20:45 ` Babu Moger
2026-08-26 19:32 ` [PATCH v5 03/16] x86/resctrl: Add PLZA configuration definitions and data structures Babu Moger
2026-09-16 5:16 ` Reinette Chatre
2026-09-16 20:53 ` Babu Moger
2026-08-26 19:32 ` [PATCH v5 04/16] fs/resctrl: Introduce kernel mode policy enum Babu Moger
2026-09-16 5:14 ` Reinette Chatre
2026-09-16 20:53 ` Babu Moger
2026-08-26 19:32 ` [PATCH v5 05/16] x86,fs/resctrl: Introduce architecture hooks to program kernel mode Babu Moger
2026-09-16 5:26 ` Reinette Chatre
2026-09-16 20:57 ` Babu Moger
2026-08-26 19:32 ` [PATCH v5 06/16] fs/resctrl: Introduce kernel mode states for resctrl Babu Moger
2026-09-16 5:28 ` Reinette Chatre
2026-09-17 14:05 ` Babu Moger
2026-08-26 19:32 ` [PATCH v5 07/16] fs/resctrl: Introduce resctrl_set_kmode_support() to register supported modes Babu Moger
2026-09-16 5:29 ` Reinette Chatre
2026-09-17 14:20 ` Babu Moger
2026-08-26 19:32 ` [PATCH v5 08/16] x86/resctrl: Expose assign_global_enable_per_cpu when PLZA is available Babu Moger
2026-08-26 19:32 ` [PATCH v5 09/16] fs/resctrl: Add interface to display supported and active kernel modes Babu Moger
2026-09-16 5:32 ` Reinette Chatre
2026-09-17 15:29 ` Babu Moger
2026-08-26 19:32 ` [PATCH v5 10/16] fs/resctrl: Add support for hidden resource group files Babu Moger
2026-09-16 5:33 ` Reinette Chatre
2026-09-17 17:26 ` Babu Moger
2026-09-17 18:31 ` Reinette Chatre
2026-09-17 18:54 ` Babu Moger
2026-08-26 19:32 ` [PATCH v5 11/16] fs/resctrl: Introduce kmode_cpus/kmode_cpus_list per rdtgroup Babu Moger
2026-09-16 5:34 ` Reinette Chatre
2026-09-17 18:19 ` Babu Moger
2026-08-26 19:32 ` [PATCH v5 12/16] fs/resctrl: Program kernel mode assignments on CPU hotplug Babu Moger
2026-09-16 5:35 ` Reinette Chatre
2026-09-17 18:26 ` Babu Moger
2026-08-26 19:32 ` [PATCH v5 13/16] fs/resctrl: Deactivate the kernel mode association when a group is removed Babu Moger
2026-09-16 5:36 ` Reinette Chatre
2026-09-17 19:25 ` Babu Moger
2026-09-17 19:48 ` Reinette Chatre
2026-08-26 19:32 ` [PATCH v5 14/16] fs/resctrl: Add interface to modify kernel mode via info/kernel_mode Babu Moger
2026-09-16 5:50 ` Reinette Chatre
2026-09-17 20:54 ` Babu Moger
2026-08-26 19:32 ` [PATCH v5 15/16] fs/resctrl: Allow user space to write kmode_cpus/kmode_cpus_list Babu Moger
2026-08-26 19:32 ` [PATCH v5 16/16] fs/resctrl: Add documentation on kernel_mode with example Babu Moger
2026-09-01 21:14 ` Luck, Tony
2026-09-01 23:28 ` Moger, Babu
2026-09-21 3:22 ` [PATCH v5 00/16] x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem Chen Yu
2026-09-21 19:27 ` Babu Moger
2026-09-22 15:04 ` Chen Yu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ae54323b-d687-4340-9134-f8eb9fad859e@amd.com \
--to=babu.moger@amd.com \
--cc=Dave.Martin@arm.com \
--cc=akpm@linux-foundation.org \
--cc=ben.horgan@arm.com \
--cc=bp@alien8.de \
--cc=chang.seok.bae@intel.com \
--cc=chao.gao@intel.com \
--cc=corbet@lwn.net \
--cc=dapeng1.mi@linux.intel.com \
--cc=darwi@linutronix.de \
--cc=dave.hansen@linux.intel.com \
--cc=ebiggers@kernel.org \
--cc=elena.reshetova@intel.com \
--cc=elver@google.com \
--cc=enelsonmoore@gmail.com \
--cc=fenghuay@nvidia.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=jlayton@kernel.org \
--cc=jmattson@google.com \
--cc=kim.phillips@amd.com \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=naveen@kernel.org \
--cc=peterz@infradead.org \
--cc=prathyushi.nangia@amd.com \
--cc=rdunlap@infradead.org \
--cc=reinette.chatre@intel.com \
--cc=ricardo.neri-calderon@linux.intel.com \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=skhan@linuxfoundation.org \
--cc=tglx@kernel.org \
--cc=tiala@microsoft.com \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox