From: Reinette Chatre <reinette.chatre@intel.com>
To: Babu Moger <babu.moger@amd.com>, <corbet@lwn.net>,
<tony.luck@intel.com>, <Dave.Martin@arm.com>,
<james.morse@arm.com>, <tglx@kernel.org>, <bp@alien8.de>,
<ben.horgan@arm.com>, <fenghuay@nvidia.com>
Cc: <skhan@linuxfoundation.org>, <x86@kernel.org>, <mingo@redhat.com>,
<dave.hansen@linux.intel.com>, <hpa@zytor.com>,
<akpm@linux-foundation.org>, <rdunlap@infradead.org>,
<peterz@infradead.org>, <feng.tang@linux.alibaba.com>,
<dapeng1.mi@linux.intel.com>, <elver@google.com>,
<enelsonmoore@gmail.com>, <kuba@kernel.org>,
<ebiggers@kernel.org>, <lirongqing@baidu.com>,
<seanjc@google.com>, <nikunj@amd.com>, <xin@zytor.com>,
<pawan.kumar.gupta@linux.intel.com>, <tiala@microsoft.com>,
<chang.seok.bae@intel.com>, <kprateek.nayak@amd.com>,
<prathyushi.nangia@amd.com>, <kim.phillips@amd.com>,
<naveen@kernel.org>, <darwi@linutronix.de>,
<elena.reshetova@intel.com>, <linux-doc@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <thomas.lendacky@amd.com>,
<eranian@google.com>, <peternewman@google.com>,
<qinyuntan@linux.alibaba.com>
Subject: Re: [RESEND PATCH v4 04/15] fs/resctrl: Introduce kernel mode (kmode) data structures
Date: Mon, 10 Aug 2026 20:03:21 -0700 [thread overview]
Message-ID: <b84e5f4a-9743-41d8-b70f-e826d5afe4fe@intel.com> (raw)
In-Reply-To: <7191fbc2a339c830e7768d7fe5e7fa0f7d65da9f.1783461016.git.babu.moger@amd.com>
Hi Babu,
On 7/7/26 2:50 PM, Babu Moger wrote:
> Kernel-mode traffic can use a different allocation and monitoring context
> than the originating user task. On x86, Privilege Level Zero Association
> (PLZA) enables the kernel to switch to a different CLOSID (and optionally
> RMID) when entering kernel mode.
>
> Architectures need a common way to name kernel-mode policies before resctrl
Please pick one term and stick with it. While reading through this series I
have come across "kernel-mode policies", "kernel-mode binding", "kernel-mode
configuration", and "kernel-mode association". Is the distinction even needed?
Could all of these just instead be: "kernel mode"?
> can report what is active or what the platform supports.
>
> Introduce enum resctrl_kernel_mode:
> - INHERIT_CTRL_AND_MON: Kernel work inherits allocation and monitoring
> from the user task (current behavior).
The issue with this "combination" mode becomes obvious in patch 7. I also
see that sashiko hinted at this issue but I am not able to see from your response
what the plan is to address this. As highlighted by patch 7 and sashiko the
"allocation" and "monitoring" features of a system are independent - a system
need not support/enable both. This should be easy to reproduce by, for example,
booting a system with needed rdt= options disabling allocation or monitoring
features.
I think it will be unexpected to a user on an allocation-only system to
see interface like:
# cat info/kernel_mode
[inherit_ctrl_and_mon]
global_assign_ctrl_inherit_mon_per_cpu:group=uninitialized
global_assign_ctrl_assign_mon_per_cpu:group=uninitialized
Should it not rather be, for example:
# cat info/kernel_mode
[inherit_ctrl]
global_assign_ctrl_per_cpu:group=uninitialized
Similarly the user input would not need to provide a monitor group when system
only supports allocation.
> - GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU: Assign allocation for kernel
> work; inherit monitoring from the user task.
I am not able to parse "Assign allocation for kernel work"
> - GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU: Assign a dedicated allocation
> and monitoring for kernel work.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> ---
...
> diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
> index 73ff522448a0..c7abed51cd5f 100644
> --- a/include/linux/resctrl.h
> +++ b/include/linux/resctrl.h
> @@ -703,6 +703,37 @@ int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable);
> */
> bool resctrl_arch_get_io_alloc_enabled(struct rdt_resource *r);
>
> +/**
> + * enum resctrl_kernel_mode - Kernel-mode control and monitor association
> + * policy.
> + *
> + * @INHERIT_CTRL_AND_MON:
> + * Kernel work inherits the allocation and monitoring from the user space
"inherits the allocation and monitoring" is very vague. I think it will help to
make things clear if this is described as the control and monitor groups being
assigned.
> + * task. On x86 this means that kernel work shares the same CLOSID and
> + * RMID as the user space task. This matches today's resctrl behavior.
"This matches today's resctrl behavior." - This cannot be expected to age well and can
be dropped.
> + *
> + * @GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU:
> + * Kernel work uses a globally assigned allocation while monitoring is
> + * inherited from the user space task. On x86 this means a CLOSID is
(same comment as above)
> + * assigned for kernel work and the RMID is inherited from the user space
> + * task. Default scope is all online CPUs; a subset may be selected via
> + * the resctrl group interface. A CTRL_MON group is bound to this mode.
> + *
> + * @GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU:
> + * Kernel work uses globally assigned allocation and monitoring. On x86
(same comment as above)
> + * this means both CLOSID and RMID are assigned for kernel work. Default
> + * scope is all online CPUs; a subset may be selected via the resctrl
> + * group interface. A CTRL_MON or MON group is bound to this mode.
> + */
> +enum resctrl_kernel_mode {
> + INHERIT_CTRL_AND_MON,
> + GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU,
> + GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU,
> + RESCTRL_KMODE_LAST = GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU,
Please drop comma on a terminator line.
> +};
> +
> +#define RESCTRL_NUM_KERNEL_MODES (RESCTRL_KMODE_LAST + 1)
> +
> extern unsigned int resctrl_rmid_realloc_threshold;
> extern unsigned int resctrl_rmid_realloc_limit;
>
Reinette
next prev parent reply other threads:[~2026-08-11 3:03 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 21:50 [RESEND PATCH v4 00/15] x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem Babu Moger
2026-07-07 21:50 ` [RESEND PATCH v4 01/15] x86/resctrl: Support Privilege Level Zero Association (PLZA) Babu Moger
2026-07-07 22:01 ` Borislav Petkov
2026-07-08 14:51 ` Babu Moger
2026-07-08 17:27 ` Borislav Petkov
2026-07-08 16:55 ` Babu Moger
2026-07-08 23:28 ` Borislav Petkov
2026-07-09 0:00 ` Namhyung Kim
2026-07-09 0:12 ` Borislav Petkov
2026-07-10 0:55 ` Namhyung Kim
2026-07-10 1:46 ` Borislav Petkov
2026-08-11 2:51 ` Reinette Chatre
2026-08-11 20:02 ` Babu Moger
2026-07-07 21:50 ` [RESEND PATCH v4 02/15] x86/resctrl: Add PLZA support to command-line options Babu Moger
2026-07-08 17:39 ` Babu Moger
2026-08-11 2:53 ` Reinette Chatre
2026-08-11 20:03 ` Babu Moger
2026-07-07 21:50 ` [RESEND PATCH v4 03/15] x86/resctrl: Add data structures and definitions for PLZA configuration Babu Moger
2026-07-08 20:20 ` Babu Moger
2026-08-11 2:58 ` Reinette Chatre
2026-08-11 21:10 ` Babu Moger
2026-08-11 23:51 ` Reinette Chatre
2026-07-07 21:50 ` [RESEND PATCH v4 04/15] fs/resctrl: Introduce kernel mode (kmode) data structures Babu Moger
2026-07-08 20:56 ` Babu Moger
2026-08-11 3:03 ` Reinette Chatre [this message]
2026-07-07 21:50 ` [RESEND PATCH v4 05/15] x86,fs/resctrl: Introduce architecture hooks to program kernel-mode Babu Moger
2026-07-08 23:04 ` Moger, Babu
2026-08-11 3:14 ` Reinette Chatre
2026-07-07 21:50 ` [RESEND PATCH v4 06/15] fs/resctrl: Introduce resctrl_set_kmode_support() to initialize supported modes Babu Moger
2026-08-11 3:16 ` Reinette Chatre
2026-07-07 21:50 ` [RESEND PATCH v4 07/15] x86/resctrl: Expose the supported PLZA kernel-mode policies during init Babu Moger
2026-07-09 15:15 ` Babu Moger
2026-07-07 21:50 ` [RESEND PATCH v4 08/15] fs/resctrl: Add interface to display supported and active kernel-mode policy Babu Moger
2026-08-11 3:18 ` Reinette Chatre
2026-07-07 21:50 ` [RESEND PATCH v4 09/15] fs/resctrl: Introduce kmode_cpus/kmode_cpus_list per rdtgroup Babu Moger
2026-08-11 3:20 ` Reinette Chatre
2026-07-07 21:50 ` [RESEND PATCH v4 10/15] fs/resctrl: Reset the kernel-mode binding when an rdtgroup is removed Babu Moger
2026-07-09 18:15 ` Babu Moger
2026-08-11 3:29 ` Reinette Chatre
2026-07-07 21:50 ` [RESEND PATCH v4 11/15] fs/resctrl: Program kernel-mode binding when CPU comes online Babu Moger
2026-07-09 20:01 ` Babu Moger
2026-07-07 21:50 ` [RESEND PATCH v4 12/15] fs/resctrl: Hide kmode_cpus[_list] on groups not bound to kernel-mode Babu Moger
2026-08-11 3:30 ` Reinette Chatre
2026-07-07 21:50 ` [RESEND PATCH v4 13/15] fs/resctrl: Add interface to modify kernel-mode via info/kernel_mode Babu Moger
2026-07-09 22:46 ` Moger, Babu
2026-08-11 3:40 ` Reinette Chatre
2026-07-07 21:50 ` [RESEND PATCH v4 14/15] fs/resctrl: Allow user space to write kmode_cpus/kmode_cpus_list Babu Moger
2026-07-09 23:14 ` Moger, Babu
2026-08-11 3:49 ` Reinette Chatre
2026-07-07 21:50 ` [RESEND PATCH v4 15/15] fs/resctrl: Add documentation on kernel_mode with example Babu Moger
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=b84e5f4a-9743-41d8-b70f-e826d5afe4fe@intel.com \
--to=reinette.chatre@intel.com \
--cc=Dave.Martin@arm.com \
--cc=akpm@linux-foundation.org \
--cc=babu.moger@amd.com \
--cc=ben.horgan@arm.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=feng.tang@linux.alibaba.com \
--cc=fenghuay@nvidia.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=kim.phillips@amd.com \
--cc=kprateek.nayak@amd.com \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lirongqing@baidu.com \
--cc=mingo@redhat.com \
--cc=naveen@kernel.org \
--cc=nikunj@amd.com \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=peternewman@google.com \
--cc=peterz@infradead.org \
--cc=prathyushi.nangia@amd.com \
--cc=qinyuntan@linux.alibaba.com \
--cc=rdunlap@infradead.org \
--cc=seanjc@google.com \
--cc=skhan@linuxfoundation.org \
--cc=tglx@kernel.org \
--cc=thomas.lendacky@amd.com \
--cc=tiala@microsoft.com \
--cc=tony.luck@intel.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.