From: Babu Moger <babu.moger@amd.com>
To: Reinette Chatre <reinette.chatre@intel.com>,
tony.luck@intel.com, bp@alien8.de, ben.horgan@arm.com
Cc: corbet@lwn.net, skhan@linuxfoundation.org, rdunlap@infradead.org,
x86@kernel.org, Dave.Martin@arm.com, james.morse@arm.com,
tglx@kernel.org, mingo@redhat.com, dave.hansen@linux.intel.com,
hpa@zytor.com, fenghuay@nvidia.com, kas@kernel.org,
rick.p.edgecombe@intel.com, akpm@linux-foundation.org,
rppt@kernel.org, dapeng1.mi@linux.intel.com, elver@google.com,
enelsonmoore@gmail.com, jlayton@kernel.org, kuba@kernel.org,
ebiggers@kernel.org, seanjc@google.com, ewanhai-oc@zhaoxin.com,
binbin.wu@linux.intel.com, peterz@infradead.org,
ashish.kalra@amd.com, superm1@kernel.org,
chang.seok.bae@intel.com, prathyushi.nangia@amd.com,
kim.phillips@amd.com, ackerleytng@google.com,
elena.reshetova@intel.com, naveen@kernel.org,
darwi@linutronix.de, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev,
kvm@vger.kernel.org, eranian@google.com, peternewman@google.com
Subject: Re: [PATCH v6 13/18] fs/resctrl: Deactivate kernel mode associations when a group is removed
Date: Mon, 19 Oct 2026 10:47:49 -0500 [thread overview]
Message-ID: <cabf7da5-e5ba-4a49-9edf-f801f344ded6@amd.com> (raw)
In-Reply-To: <08e1de88-cab0-4caa-87f2-94db0f698ba7@intel.com>
Hi Reinette,
On 10/15/26 10:43, Reinette Chatre wrote:
> Hi Babu,
>
> On 10/1/26 8:10 AM, Babu Moger wrote:
>> The active kernel mode association is backed by either a CTRL_MON or
>> MON group.
>
> This context does not reflect the code at this point in series but what
> behavior will be after entire series is applied. It is also written as
> general but specific to the global per-CPU kernel mode.
>
>> When the backing group is removed, or when resctrl is unmounted, clear
>> the programmed association and restore the default settings.
>
> Please provide more context to user and help reader to understand what the
> patch does without needing to decipher the patch.
"The global per-CPU kernel mode, RESCTRL_GLOBAL_ENABLE_PER_CPU, allows
kernel work to use allocation and monitoring associations that differ
from those of the originating user task. When the mode is active,
"info/kernel_mode" displays the backing mode. If the backing group is
removed, or resctrl is unmounted, the association becomes invalid.
Clear the programmed association and revert the kernel mode to the
default "inherit user" behavior. This ensures that kernel work continues
to use the allocation and monitoring associations of the originating
user task until a new kernel mode association is configured.
Document this user-visible behavior in resctrl.rst."
>
> For example, "restore the default settings" is a very vague way to
> describe that removing the group backing the global per-CPU kernel mode
> automatically switches the kernel mode to "inherit user". Please explain
> at high level what the code does and why. As a hypothetical, why not
> keep the kernel mode as "global per-CPU kernel mode" but switch the assigned
> group to the default group? This would match most other similar resctrl behaviors,
> no?
My assuption, you are not asking me to change it to "global per-CPU
kernel mode" when the group is removed.
>
> This is also user visible behavior that should be documented in resctrl.rst.
Will add a line under "inherit_user" documentation.
>
>> ---
>> fs/resctrl/rdtgroup.c | 44 +++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 44 insertions(+)
>>
>> diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
>> index f5c7790f7970..0cdc868a55b1 100644
>> --- a/fs/resctrl/rdtgroup.c
>> +++ b/fs/resctrl/rdtgroup.c
>> @@ -1167,6 +1167,36 @@ static void resctrl_kmode_global_offline_cpu(unsigned int cpu)
>> resctrl_configure_kmode_global(cpumask_of(cpu), rdtgrp, false);
>> }
>>
>> +/*
>> + * Disable the association on @rdtgrp's kmode_cpu_mask, clear the mask, and
>> + * hide the group's kmode_cpus files.
>
> "hide the group's kmode_cpus files"? Does not match the code below.
> Even so, the comments just narrate the function.
Yea. Will remove "hide the group's kmode_cpus files" detail.
>
>> + */
>> +static void rdtgroup_kmode_global_deactivate(struct rdtgroup *rdtgrp)
>> +{
>> + resctrl_configure_kmode_global(&rdtgrp->kmode_cpu_mask, rdtgrp, false);
>> + cpumask_clear(&rdtgrp->kmode_cpu_mask);
>> +}
>> +
>> +/*
>> + * rdtgroup_kmode_global_detach() - Detach @rdtgrp from the global per-CPU mode
>> + * @rdtgrp: Resctrl group being removed or torn down.
>> + *
>> + * If @rdtgrp backs the active association, disable it, clear kernel mode
>> + * state, and restore RESCTRL_INHERIT_USER.
>> + */
>> +static void rdtgroup_kmode_global_detach(struct rdtgroup *rdtgrp)
>> +{
>> + if (resctrl_kmode.rdtgrp != rdtgrp)
>
> Please do not use tests on resctrl_kmode.rdtgrp as synonym for
> resctrl_kmode.active == RESCTRL_GLOBAL_ENABLE_PER_CPU.
Not really. This was a check to make sure kernel mode is pointing to
correct group that is being removed.
>
>> + return;
>> +
>> + rdtgroup_kmode_global_deactivate(rdtgrp);
>> +
>> + resctrl_kmode.rdtgrp = NULL;
>> + resctrl_kmode.kmode_cur = RESCTRL_INHERIT_USER;
>> + resctrl_kmode.ctrl = KMODE_ASSIGN;
>> + resctrl_kmode.mon = KMODE_ASSIGN;
>> +}
>
> There seems to be some duplication between rdtgroup_kmode_global_detach() and
> resctrl_kmode_switch(). Since the contract is already established that
> disabling RESCTRL_GLOBAL_ENABLE_PER_CPU enables RESCTRL_INHERIT_USER, could this
> reset to RESCTRL_INHERIT_USER not just be done in rdtgroup_kmode_global_deactivate()
> without duplicating it in rdtgroup_kmode_global_detach() and resctrl_kmode_switch()?
>
> With that done, it looks like rdtgroup_kmode_global_detach() could just be
> dropped if rdtgroup_kmode_global_deactivate() gets the check to ensure the
> group needs removing?
>
Yea. I may have to re-organize few things. I can do everything with
rdtgroup_kmode_global_deactivate() and rdtgroup_kmode_global_activate().
And remove both rdtgroup_kmode_global_detach() and resctrl_kmode_switch().
>
>> +
>> void *rdt_kn_parent_priv(struct kernfs_node *kn)
>> {
>> /*
>> @@ -3228,6 +3258,7 @@ static void free_all_child_rdtgrp(struct rdtgroup *rdtgrp)
>>
>> head = &rdtgrp->mon.crdtgrp_list;
>> list_for_each_entry_safe(sentry, stmp, head, mon.crdtgrp_list) {
>> + rdtgroup_kmode_global_detach(sentry);
>> rdtgroup_unassign_cntrs(sentry);
>> free_rmid(sentry->closid, sentry->mon.rmid);
>> list_del(&sentry->mon.crdtgrp_list);
>> @@ -3265,6 +3296,7 @@ static void rmdir_all_sub(void)
>> cpumask_or(&rdtgroup_default.cpu_mask,
>> &rdtgroup_default.cpu_mask, &rdtgrp->cpu_mask);
>>
>> + rdtgroup_kmode_global_detach(rdtgrp);
>> rdtgroup_unassign_cntrs(rdtgrp);
>>
>> if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP ||
>> @@ -3360,6 +3392,7 @@ static void resctrl_fs_teardown(void)
>> return;
>>
>> rmdir_all_sub();
>> + rdtgroup_kmode_global_detach(&rdtgroup_default);
>> rdtgroup_unassign_cntrs(&rdtgroup_default);
>> mon_put_kn_priv();
>> rdt_pseudo_lock_release();
>> @@ -4395,6 +4428,8 @@ static int rdtgroup_rmdir_mon(struct rdtgroup *rdtgrp, cpumask_var_t tmpmask)
>> u32 closid, rmid;
>> int cpu;
>>
>> + rdtgroup_kmode_global_detach(rdtgrp);
>> +
>> /* Give any tasks back to the parent group */
>> rdt_move_group_tasks(rdtgrp, prdtgrp, tmpmask);
>>
>> @@ -4442,9 +4477,18 @@ static int rdtgroup_ctrl_remove(struct rdtgroup *rdtgrp)
>>
>> static int rdtgroup_rmdir_ctrl(struct rdtgroup *rdtgrp, cpumask_var_t tmpmask)
>> {
>> + struct rdtgroup *sentry;
>> u32 closid, rmid;
>> int cpu;
>>
>> + /*
>> + * A monitor group uses its parent's CLOSID. Detach a child that
>> + * backs the association before that CLOSID is freed.
>
> Why does this have to be done before the CLOSID is freed? The monitor groups
> are cleared later from free_all_child_rdtgrp() that will call
> rdtgroup_kmode_global_detach() for every monitor again.
Yea. May not be required. Will remove.
Thanks
Babu
next prev parent reply other threads:[~2026-10-19 15:47 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 15:10 [PATCH v6 00/18] x86,fs/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem Babu Moger
2026-10-01 15:10 ` [PATCH v6 01/18] x86/cpufeatures: Support Privilege Level Zero Association (PLZA) Babu Moger
2026-10-15 14:16 ` Reinette Chatre
2026-10-15 23:02 ` Babu Moger
2026-10-01 15:10 ` [PATCH v6 02/18] x86/resctrl: Add PLZA support to command-line options Babu Moger
2026-10-15 14:17 ` Reinette Chatre
2026-10-15 23:03 ` Babu Moger
2026-10-01 15:10 ` [PATCH v6 03/18] x86/resctrl: Add PLZA configuration definitions and data structures Babu Moger
2026-10-15 14:22 ` Reinette Chatre
2026-10-15 23:07 ` Babu Moger
2026-10-19 16:16 ` Reinette Chatre
2026-10-01 15:10 ` [PATCH v6 04/18] fs/resctrl: Introduce kernel mode enum Babu Moger
2026-10-15 14:44 ` Reinette Chatre
2026-10-15 23:09 ` Babu Moger
2026-10-19 16:17 ` Reinette Chatre
2026-10-01 15:10 ` [PATCH v6 05/18] x86,arm,fs/resctrl: Introduce architecture hook to program global kernel mode Babu Moger
2026-10-15 14:30 ` Reinette Chatre
2026-10-15 23:12 ` Moger, Babu
2026-10-01 15:10 ` [PATCH v6 06/18] fs/resctrl: Introduce kernel mode states for resctrl Babu Moger
2026-10-15 14:37 ` Reinette Chatre
2026-10-16 15:10 ` Moger, Babu
2026-10-19 16:18 ` Reinette Chatre
2026-10-20 14:20 ` Babu Moger
2026-10-01 15:10 ` [PATCH v6 07/18] fs/resctrl: Introduce resctrl_set_kmode_support() to register supported modes Babu Moger
2026-10-15 14:40 ` Reinette Chatre
2026-10-16 15:27 ` Moger, Babu
2026-10-19 16:19 ` Reinette Chatre
2026-10-20 14:46 ` Babu Moger
2026-10-01 15:10 ` [PATCH v6 08/18] x86/resctrl: Register RESCTRL_GLOBAL_ENABLE_PER_CPU when PLZA is available Babu Moger
2026-10-15 14:46 ` Reinette Chatre
2026-10-16 15:50 ` Moger, Babu
2026-10-01 15:10 ` [PATCH v6 09/18] fs/resctrl: Add interface to display kernel mode status Babu Moger
2026-10-15 15:16 ` Reinette Chatre
2026-10-16 19:10 ` Moger, Babu
2026-10-19 16:20 ` Reinette Chatre
2026-10-01 15:10 ` [PATCH v6 10/18] fs/resctrl: Add support for hidden resource group files Babu Moger
2026-10-15 15:27 ` Reinette Chatre
2026-10-16 20:53 ` Moger, Babu
2026-10-19 16:22 ` Reinette Chatre
2026-10-01 15:10 ` [PATCH v6 11/18] fs/resctrl: Introduce kmode_cpus/kmode_cpus_list per rdtgroup Babu Moger
2026-10-15 15:31 ` Reinette Chatre
2026-10-16 21:33 ` Moger, Babu
2026-10-19 16:34 ` Reinette Chatre
2026-10-01 15:10 ` [PATCH v6 12/18] fs/resctrl: Add CPU hotplug support for kernel mode associations Babu Moger
2026-10-15 15:33 ` Reinette Chatre
2026-10-16 22:21 ` Moger, Babu
2026-10-01 15:10 ` [PATCH v6 13/18] fs/resctrl: Deactivate kernel mode associations when a group is removed Babu Moger
2026-10-15 15:43 ` Reinette Chatre
2026-10-19 15:47 ` Babu Moger [this message]
2026-10-19 16:37 ` Reinette Chatre
2026-10-01 15:10 ` [PATCH v6 14/18] fs/resctrl: Control visibility of global per-CPU kernel mode group files Babu Moger
2026-10-15 15:46 ` Reinette Chatre
2026-10-19 16:31 ` Babu Moger
2026-10-19 22:00 ` Reinette Chatre
2026-10-01 15:10 ` [PATCH v6 15/18] fs/resctrl: Reject mode changes for groups backing kernel mode Babu Moger
2026-10-15 15:49 ` Reinette Chatre
2026-10-19 17:43 ` Babu Moger
2026-10-19 22:01 ` Reinette Chatre
2026-10-01 15:10 ` [PATCH v6 16/18] fs/resctrl: Add interface to modify kernel mode via info/kernel_mode Babu Moger
2026-10-15 16:07 ` Reinette Chatre
2026-10-20 0:21 ` Babu Moger
2026-10-01 15:10 ` [PATCH v6 17/18] fs/resctrl: Allow user space to write kmode_cpus/kmode_cpus_list Babu Moger
2026-10-01 15:10 ` [PATCH v6 18/18] fs/resctrl: Add kernel mode documentation and examples Babu Moger
2026-10-17 0:13 ` [PATCH v6 00/18] x86,fs/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem Drew Fustini
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=cabf7da5-e5ba-4a49-9edf-f801f344ded6@amd.com \
--to=babu.moger@amd.com \
--cc=Dave.Martin@arm.com \
--cc=ackerleytng@google.com \
--cc=akpm@linux-foundation.org \
--cc=ashish.kalra@amd.com \
--cc=ben.horgan@arm.com \
--cc=binbin.wu@linux.intel.com \
--cc=bp@alien8.de \
--cc=chang.seok.bae@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=eranian@google.com \
--cc=ewanhai-oc@zhaoxin.com \
--cc=fenghuay@nvidia.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=jlayton@kernel.org \
--cc=kas@kernel.org \
--cc=kim.phillips@amd.com \
--cc=kuba@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=mingo@redhat.com \
--cc=naveen@kernel.org \
--cc=peternewman@google.com \
--cc=peterz@infradead.org \
--cc=prathyushi.nangia@amd.com \
--cc=rdunlap@infradead.org \
--cc=reinette.chatre@intel.com \
--cc=rick.p.edgecombe@intel.com \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=skhan@linuxfoundation.org \
--cc=superm1@kernel.org \
--cc=tglx@kernel.org \
--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