From: Reinette Chatre <reinette.chatre@intel.com>
To: "Moger, Babu" <bmoger@amd.com>, Babu Moger <babu.moger@amd.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"tony.luck@intel.com" <tony.luck@intel.com>,
"Dave.Martin@arm.com" <Dave.Martin@arm.com>,
"james.morse@arm.com" <james.morse@arm.com>,
"tglx@kernel.org" <tglx@kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"bp@alien8.de" <bp@alien8.de>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>
Cc: "skhan@linuxfoundation.org" <skhan@linuxfoundation.org>,
"x86@kernel.org" <x86@kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"juri.lelli@redhat.com" <juri.lelli@redhat.com>,
"vincent.guittot@linaro.org" <vincent.guittot@linaro.org>,
"dietmar.eggemann@arm.com" <dietmar.eggemann@arm.com>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"bsegall@google.com" <bsegall@google.com>,
"mgorman@suse.de" <mgorman@suse.de>,
"vschneid@redhat.com" <vschneid@redhat.com>,
"kas@kernel.org" <kas@kernel.org>,
"rick.p.edgecombe@intel.com" <rick.p.edgecombe@intel.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"pmladek@suse.com" <pmladek@suse.com>,
"rdunlap@infradead.org" <rdunlap@infradead.org>,
"dapeng1.mi@linux.intel.com" <dapeng1.mi@linux.intel.com>,
"kees@kernel.org" <kees@kernel.org>,
"elver@google.com" <elver@google.com>,
"paulmck@kernel.org" <paulmck@kernel.org>,
"lirongqing@baidu.com" <lirongqing@baidu.com>,
"safinaskar@gmail.com" <safinaskar@gmail.com>,
"fvdl@google.com" <fvdl@google.com>,
"seanjc@google.com" <seanjc@google.com>,
"pawan.kumar.gupta@linux.intel.com"
<pawan.kumar.gupta@linux.intel.com>,
"xin@zytor.com" <xin@zytor.com>,
"tiala@microsoft.com" <tiala@microsoft.com>,
"chang.seok.bae@intel.com" <chang.seok.bae@intel.com>,
"Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
"elena.reshetova@intel.com" <elena.reshetova@intel.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"eranian@google.com" <eranian@google.com>,
"peternewman@google.com" <peternewman@google.com>
Subject: Re: [PATCH v2 00/16] fs,x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem
Date: Tue, 21 Apr 2026 19:56:23 -0700 [thread overview]
Message-ID: <ed0d2463-edbf-42df-b345-b83da356e865@intel.com> (raw)
In-Reply-To: <39da36be-40a3-45cb-8e49-12dbb59aca74@amd.com>
Hi Babu,
On 4/21/26 5:17 PM, Moger, Babu wrote:
> On 4/21/2026 5:44 PM, Reinette Chatre wrote:
>> On 4/21/26 3:04 PM, Moger, Babu wrote:
>>> That said, I agree we need to support this. Without it, we won’t be able to move the group from PLZA to non-PLZA.
>>>
>>> # cat info/kernel_mode
>>> inherit_ctrl_and_mon:
>>> global_assign_ctrl_assign_mon_per_cpu:group=uninitialized
>>> [global_assign_ctrl_assign_mon_per_cpu]:group=ctrl1/mon1/
>>
>> Like above where the listing is inconsistent. Is this what you mean?
>
> I meant the listing of "inherit_ctrl_and_mon" does not have groups while other modes have it.
I think this is ok since it does not need a group or any other (for now?) property.
What issues do you foresee here?
>>
>> sidenote: Should the last line be "[global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/]"?
>
> Yes.
>
>>
>>>
>>> # echo "inherit_ctrl_and_mon:group=ctrl1/mon1/" > info/kernel_mode
>>
>> This does not look right. Why is a "group" property needed here? Can the mode not just
>> be set by itself? Specifically, why not just:
>>
>> # echo "inherit_ctrl_and_mon" > info/kernel_mode
>
> We can go with this based on your another comment below. While changing the mode use the defaults if properties are not provided.
>
>
>>
>> This reminds me that there is still an open remaining from
>> https://lore.kernel.org/lkml/71099958-1ddf-40dc-8a3c-aa13d0c56fee@intel.com/
>> Specifically this from that message:
>> The named fields could be made optional, if group is omitted then it will become the
>> default resource group, and if cpus/cpus_list is omitted then it will default to all CPUs.
>> This may not be intuitive since a user may expect that not mentioning a field means
>> that the field is left untouched. Have you considered this scenario in your proposal?
>>
>> I think this needs some clear description of behavior wrt properties, for example:
>> - Is it required to provide all properties on each write? More specifically, can user expect there
>> to be "default" values when a property is not provided or is user required to provide a value
>> for each property? We need to be careful here because we do not want user scripts to fail when a new
>> property is added in the future. What if resctrl specifies that if user space does not provide
>> a property then resctrl will pick a default. For example, if user runs:
>> # echo "global_assign_ctrl_assign_mon_per_cpu" > info/kernel_mode
>> then resctrl will switch to "global_assign_ctrl_assign_mon_per_cpu" mode initialized to
>> the default group.
>> I am not sure if resctrl needs to support re-configuration of modes in the future where the
>> mode stays the same but a property changes? Consider, for example,
>>
>> # cat info/kernel_mode
>> [inherit_ctrl_and_mon:]
>> global_assign_ctrl_assign_mon_per_cpu:group=uninitialized
>>
>> # echo "global_assign_ctrl_assign_mon_per_cpu" > info/kernel_mode
>> /*
>> * resctrl switches to "global_assign_ctrl_assign_mon_per_cpu" mode and sets
>> * PLZA group to default group
>> */
>> # cat info/kernel_mode
>> inherit_ctrl_and_mon:
>> [global_assign_ctrl_assign_mon_per_cpu:group=//]
>> # echo "global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/" > info/kernel_mode
>> /*
>> * resctrl stays in "global_assign_ctrl_assign_mon_per_cpu" mode and sets
>> * PLZA group to default group
>> */
>
> I think you meant "PLZA group to ctrl1/mon1/" here.
Indeed, yes. Thank you.
>
>> # cat info/kernel_mode
>> inherit_ctrl_and_mon:
>> [global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/]
>> # echo "global_assign_ctrl_assign_mon_per_cpu" > info/kernel_mode
>> /*
>> * TBD: should resctrl switch back to default group or just keep
>> * group as ctrl1/mon1/ ?
>> */
>>
>> resctrl could thus specify different behavior for switching to a mode where all properties
>> not specified obtains default values and re-configuring a mode where only specified
>> properties are changed. That means, the "TBD" above would be that the group stays
>> as ctrl1/mon1/. So,
>> # cat info/kernel_mode
>> inherit_ctrl_and_mon:
>> [global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/]
>>
>> What do you think?
>
> Yes. Sure. We can do that. We only have 2 properties now (mode and group). We should be able to handle that.
Thank you for considering.
Reinette
next prev parent reply other threads:[~2026-04-22 2:58 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-12 20:36 [PATCH v2 00/16] fs,x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem Babu Moger
2026-03-12 20:36 ` [PATCH v2 01/16] fs/resctrl: Add kernel mode (kmode) data structures and arch hook Babu Moger
2026-03-24 22:51 ` Reinette Chatre
2026-03-26 18:41 ` Babu Moger
2026-03-12 20:36 ` [PATCH v2 02/16] fs, x86/resctrl: Add architecture routines for kernel mode initialization Babu Moger
2026-03-24 22:53 ` Reinette Chatre
2026-03-26 19:10 ` Babu Moger
2026-03-12 20:36 ` [PATCH v2 03/16] fs/resctrl: Add info/kernel_mode file to show kernel mode options Babu Moger
2026-03-12 20:36 ` [PATCH v2 04/16] x86/resctrl: Support Privilege-Level Zero Association (PLZA) Babu Moger
2026-03-12 20:36 ` [PATCH v2 05/16] x86/resctrl: Initialize supported kernel modes when CPUID reports PLZA Babu Moger
2026-03-12 20:36 ` [PATCH v2 06/16] resctrl: Introduce kmode static key enable/disable helpers Babu Moger
2026-03-12 20:36 ` [PATCH v2 07/16] x86/resctrl: Add data structures and definitions for PLZA configuration Babu Moger
2026-03-12 20:36 ` [PATCH v2 08/16] x86/resctrl: Add per-CPU and per-task kernel mode state Babu Moger
2026-03-12 20:36 ` [PATCH v2 09/16] x86,fs/resctrl: Add the functionality to configure PLZA Babu Moger
2026-03-13 14:05 ` kernel test robot
2026-03-15 4:55 ` kernel test robot
2026-03-12 20:36 ` [PATCH v2 10/16] x86/resctrl: Add PLZA state tracking and context switch handling Babu Moger
2026-03-12 20:36 ` [PATCH v2 11/16] fs/resctrl: Add write handler for info/kernel_mode Babu Moger
2026-03-12 20:36 ` [PATCH v2 12/16] fs/resctrl: Add info/kernel_mode_assignment to show kernel-mode rdtgroup Babu Moger
2026-03-12 20:36 ` [PATCH v2 13/16] fs/resctrl: Add write interface for kernel_mode_assignment Babu Moger
2026-03-12 20:36 ` [PATCH v2 14/16] fs/resctrl: Update kmode configuration when cpu_mask changes Babu Moger
2026-03-12 20:37 ` [PATCH v2 15/16] x86/resctrl: Refactor show_rdt_tasks() to support PLZA tasks Babu Moger
2026-03-12 20:37 ` [PATCH v2 16/16] fs/resctrl: Add per-task kmode enable support via rdtgroup Babu Moger
2026-03-24 6:15 ` [PATCH v2 00/16] fs,x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem Askar Safin
2026-03-24 22:51 ` Reinette Chatre
2026-03-26 17:12 ` Babu Moger
2026-03-27 22:11 ` Reinette Chatre
2026-03-30 18:46 ` Babu Moger
2026-03-31 22:24 ` Reinette Chatre
2026-04-06 22:45 ` Babu Moger
2026-04-07 17:48 ` Reinette Chatre
2026-04-08 1:01 ` Babu Moger
2026-04-08 4:45 ` Reinette Chatre
2026-04-08 20:45 ` Babu Moger
2026-04-08 21:24 ` Reinette Chatre
2026-04-08 23:07 ` Moger, Babu
2026-04-08 23:41 ` Reinette Chatre
2026-04-09 17:19 ` Moger, Babu
2026-04-09 17:26 ` Reinette Chatre
2026-04-09 18:05 ` Moger, Babu
2026-04-09 20:50 ` Reinette Chatre
2026-04-09 23:42 ` Moger, Babu
2026-04-10 3:41 ` Reinette Chatre
2026-04-10 22:52 ` Moger, Babu
2026-04-20 19:38 ` Babu Moger
2026-04-20 22:03 ` Reinette Chatre
2026-04-20 22:59 ` Moger, Babu
2026-04-20 23:34 ` Reinette Chatre
2026-04-21 0:40 ` Moger, Babu
2026-04-21 3:17 ` Reinette Chatre
2026-04-21 15:08 ` Babu Moger
2026-04-21 16:15 ` Reinette Chatre
2026-04-21 16:46 ` Babu Moger
2026-04-21 17:35 ` Reinette Chatre
2026-04-21 18:19 ` Babu Moger
2026-04-21 20:57 ` Reinette Chatre
2026-04-21 22:04 ` Moger, Babu
2026-04-21 22:44 ` Reinette Chatre
2026-04-22 0:17 ` Moger, Babu
2026-04-22 2:56 ` Reinette Chatre [this message]
2026-04-22 21:42 ` Moger, Babu
2026-04-21 0:03 ` Luck, Tony
2026-04-21 0:21 ` Reinette Chatre
2026-04-21 15:11 ` Luck, Tony
2026-04-21 16:12 ` Reinette Chatre
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=ed0d2463-edbf-42df-b345-b83da356e865@intel.com \
--to=reinette.chatre@intel.com \
--cc=Dave.Martin@arm.com \
--cc=Thomas.Lendacky@amd.com \
--cc=akpm@linux-foundation.org \
--cc=babu.moger@amd.com \
--cc=bmoger@amd.com \
--cc=bp@alien8.de \
--cc=bsegall@google.com \
--cc=chang.seok.bae@intel.com \
--cc=corbet@lwn.net \
--cc=dapeng1.mi@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dietmar.eggemann@arm.com \
--cc=elena.reshetova@intel.com \
--cc=elver@google.com \
--cc=eranian@google.com \
--cc=fvdl@google.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=juri.lelli@redhat.com \
--cc=kas@kernel.org \
--cc=kees@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lirongqing@baidu.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=peternewman@google.com \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rdunlap@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=rostedt@goodmis.org \
--cc=safinaskar@gmail.com \
--cc=seanjc@google.com \
--cc=skhan@linuxfoundation.org \
--cc=tglx@kernel.org \
--cc=tiala@microsoft.com \
--cc=tony.luck@intel.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=x86@kernel.org \
--cc=xin@zytor.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.