Linux Documentation
 help / color / mirror / Atom feed
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>,
	<dave.hansen@linux.intel.com>
Cc: <skhan@linuxfoundation.org>, <x86@kernel.org>, <mingo@redhat.com>,
	<hpa@zytor.com>, <akpm@linux-foundation.org>,
	<rdunlap@infradead.org>, <pawan.kumar.gupta@linux.intel.com>,
	<feng.tang@linux.alibaba.com>, <dapeng1.mi@linux.intel.com>,
	<kees@kernel.org>, <elver@google.com>, <lirongqing@baidu.com>,
	<paulmck@kernel.org>, <bhelgaas@google.com>, <seanjc@google.com>,
	<alexandre.chartre@oracle.com>, <yazen.ghannam@amd.com>,
	<peterz@infradead.org>, <chang.seok.bae@intel.com>,
	<kim.phillips@amd.com>, <xin@zytor.com>, <naveen@kernel.org>,
	<thomas.lendacky@amd.com>, <linux-doc@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <eranian@google.com>,
	<peternewman@google.com>
Subject: Re: [PATCH v3 07/12] fs/resctrl: Add info/kernel_mode for kernel-mode policy introspection
Date: Tue, 16 Jun 2026 16:38:56 -0700	[thread overview]
Message-ID: <2429a51a-92ad-4810-bee9-44bd6fba3443@intel.com> (raw)
In-Reply-To: <549bf0fadf1cedb5938599be58e53b7464c939b5.1777591497.git.babu.moger@amd.com>

Hi Babu,

How should "introspection" as used in subject be interpreted? This just
displays the supported and active kernel modes to user space, no?

On 4/30/26 4:24 PM, Babu Moger wrote:
> There is no user-visible way today to see which kernel-mode CLOSID/RMID
> policies the running kernel supports, which one is active, or which
> resctrl group currently owns the kernel CLOSID/RMID.

Why should there be? This is a new feature being added in this series.
No need to write this as a bugfix.

> 
> Add a read-only top-level sysfs file, info/kernel_mode.  It emits one
> line per mode advertised in resctrl_kcfg.kmode, in stable lowercase
> spelling derived from enum resctrl_kernel_modes, e.g.:

All these changelogs feel so strange ... as though they are written by
somebody who simultaneously has no and full knowledge of resctrl.
These verbatim descriptions of what the code does is not necessary. Please
start with why the patch is needed.

> 
>   [inherit_ctrl_and_mon:group=//]

This is unexpected. There should be no group associated with this default mode.
This is how I interpreted our previous discussion ending:
https://lore.kernel.org/lkml/6709398b-269d-47b5-9b41-084f410bb1a6@amd.com/

>   global_assign_ctrl_inherit_mon_per_cpu:group=none
>   global_assign_ctrl_assign_mon_per_cpu:group=none
> 
> The effective policy (resctrl_kcfg.kmode_cur) is wrapped in square

(needs imperative - please check all changelogs)

> brackets and its :group= suffix names the resctrl group currently
> bound to the kernel CLOSID/RMID (resctrl_kcfg.k_rdtgrp), formatted as
> <ctrl>/<mon>/ with empty components left blank.  Inactive modes are
> reported as :group=none.
> 
> rdtgroup_mutex is held while printing, matching other info/ show paths.

No need to describe details that can be seen from patch.

> 
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> ---
> v3: New patch to handle the changed interface file info/kernel_mode.
>     Changed the group name to "none" if kmode binding is not done.
>     Reinette suggested "uninitialized". "none" seemed more relevent.
> ---
>  fs/resctrl/rdtgroup.c | 74 +++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 74 insertions(+)
> 
> diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
> index a7bfc74897cc..9cdcfa64c4a2 100644
> --- a/fs/resctrl/rdtgroup.c
> +++ b/fs/resctrl/rdtgroup.c
> @@ -988,6 +988,73 @@ static int rdt_last_cmd_status_show(struct kernfs_open_file *of,
>  	return 0;
>  }
>  
> +/* Sysfs lines for info/kernel_mode; indexed by &enum resctrl_kernel_modes */
> +static const char * const resctrl_mode_str[] = {
> +	[INHERIT_CTRL_AND_MON]			= "inherit_ctrl_and_mon",
> +	[GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU] = "global_assign_ctrl_inherit_mon_per_cpu",
> +	[GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU]	= "global_assign_ctrl_assign_mon_per_cpu",

Please make alignment consistent.

> +};
> +
> +static_assert(ARRAY_SIZE(resctrl_mode_str) == RESCTRL_NUM_KERNEL_MODES);
> +
> +/**
> + * resctrl_kernel_mode_show() - Enumerate supported and effective kernel-mode policies

"Enumerate" -> "Display"?

> + * @of: kernfs open file
> + * @seq: output seq_file
> + * @v: unused
> + *
> + * Emits one line per mode advertised in resctrl_kcfg.kmode (each mode is one
> + * BIT(index) per &enum resctrl_kernel_modes).  Every line carries a

Above is clear from the code. Please instead describe what this means.

> + * ":group=<name>" suffix:
> + *
> + *   - The effective policy (whose BIT matches resctrl_kcfg.kmode_cur) is
> + *     wrapped in square brackets and <name> is the resctrl group that
> + *     currently owns the kernel CLOSID/RMID (resctrl_kcfg.k_rdtgrp),
> + *     formatted as "<ctrl>/<mon>/".  A component is left empty when it
> + *     does not apply: an RDTCTRL_GROUP emits "<ctrl>//", an RDTMON_GROUP
> + *     under the default control group emits "/<mon>/", and an RDTMON_GROUP
> + *     under a named control group emits "<ctrl>/<mon>/".
> + *
> + *   - Other supported but inactive modes are emitted without brackets and
> + *     <name> is reported as "none".
> + *
> + * Context: Called under rdtgroup_mutex like other resctrl sysfs show paths.

This does not look accurate since it is not called with mutex held but instead
takes the mutex itself. Also no need to refer to what other code does.

> + */
> +static int resctrl_kernel_mode_show(struct kernfs_open_file *of,
> +				    struct seq_file *seq, void *v)
> +{
> +	struct rdtgroup *rdtgrp;
> +	const char *ctrl, *mon;
> +	int i;
> +
> +	mutex_lock(&rdtgroup_mutex);
> +	for (i = 0; i < RESCTRL_NUM_KERNEL_MODES; i++) {
> +		if (!(resctrl_kcfg.kmode & BIT(i)))
> +			continue;
> +
> +		if (resctrl_kcfg.kmode_cur != BIT(i)) {
> +			seq_printf(seq, "%s:group=none\n",
> +				   resctrl_mode_str[i]);
> +			continue;
> +		}
> +
> +		rdtgrp = resctrl_kcfg.k_rdtgrp;
> +		ctrl = "";
> +		mon = "";
> +		if (rdtgrp->type == RDTMON_GROUP) {
> +			if (rdtgrp->mon.parent != &rdtgroup_default)
> +				ctrl = rdtgrp->mon.parent->kn->name;

Isn't default group's kn->name is initialized correctly via
rdtgroup_setup_root()->kernfs_create_root()->__kernfs_new_node(root, NULL, "", ...) ?

> +			mon = rdtgrp->kn->name;
> +		} else {
> +			ctrl = rdtgrp->kn->name;
> +		}

Can the names not just be initialized directly from kn->name?


> +		seq_printf(seq, "[%s:group=%s/%s/]\n",
> +			   resctrl_mode_str[i], ctrl, mon);

This is not where I understood our discussion landed. I expected that the display will
reflect what can/should be assigned in a mode. For example, mode "inherit_ctrl_and_mon"
does not have an associated resource group and should thus not display one, 
"global_assign_ctrl_inherit_mon_per_cpu" can only be assigned a control group and
should thus not display a monitor group also.

> +	}
> +	mutex_unlock(&rdtgroup_mutex);
> +	return 0;
> +}
> +
>  void *rdt_kn_parent_priv(struct kernfs_node *kn)
>  {
>  	/*
> @@ -1891,6 +1958,13 @@ static struct rftype res_common_files[] = {
>  		.seq_show	= rdt_last_cmd_status_show,
>  		.fflags		= RFTYPE_TOP_INFO,
>  	},
> +	{
> +		.name		= "kernel_mode",
> +		.mode		= 0444,
> +		.kf_ops		= &rdtgroup_kf_single_ops,
> +		.seq_show	= resctrl_kernel_mode_show,
> +		.fflags		= RFTYPE_TOP_INFO,
> +	},
>  	{
>  		.name		= "mbm_assign_on_mkdir",
>  		.mode		= 0644,

Reinette

  reply	other threads:[~2026-06-16 23:39 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-30 23:24 [PATCH v3 00/12] [PATCH v3 00/12] x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem Babu Moger
2026-04-30 23:24 ` [PATCH v3 01/12] x86/resctrl: Support Privilege-Level Zero Association (PLZA) Babu Moger
2026-06-11 23:23   ` Reinette Chatre
2026-06-12 16:56     ` Moger, Babu
2026-06-12 17:00       ` Moger, Babu
2026-06-17  0:00       ` Reinette Chatre
2026-04-30 23:24 ` [PATCH v3 02/12] x86/resctrl: Add data structures and definitions for PLZA configuration Babu Moger
2026-06-11 23:40   ` Reinette Chatre
2026-06-12 15:40     ` Luck, Tony
2026-06-12 17:46       ` Moger, Babu
2026-06-12 17:32     ` Moger, Babu
2026-06-12 17:49       ` Moger, Babu
2026-04-30 23:24 ` [PATCH v3 03/12] fs/resctrl: Add kernel mode (kmode) data structures and arch hook Babu Moger
2026-06-16 23:30   ` Reinette Chatre
2026-04-30 23:24 ` [PATCH v3 04/12] x86,fs/resctrl: Program PLZA through kmode arch hooks Babu Moger
2026-05-19 20:59   ` Luck, Tony
2026-05-20 17:49     ` Babu Moger
2026-05-20 22:16       ` Luck, Tony
2026-05-20 23:09         ` Moger, Babu
2026-06-11 11:44           ` Peter Newman
2026-06-11 14:46             ` Babu Moger
2026-06-16 23:33   ` Reinette Chatre
2026-04-30 23:24 ` [PATCH v3 05/12] x86/resctrl: Initialize supported kernel modes for PLZA Babu Moger
2026-06-16 23:35   ` Reinette Chatre
2026-04-30 23:24 ` [PATCH v3 06/12] fs/resctrl: Initialize the global kernel-mode policy at subsystem init Babu Moger
2026-06-16 23:36   ` Reinette Chatre
2026-04-30 23:24 ` [PATCH v3 07/12] fs/resctrl: Add info/kernel_mode for kernel-mode policy introspection Babu Moger
2026-06-16 23:38   ` Reinette Chatre [this message]
2026-04-30 23:24 ` [PATCH v3 08/12] fs/resctrl: Make info/kernel_mode writable and identify the bound group Babu Moger
2026-06-16 23:42   ` Reinette Chatre
2026-04-30 23:24 ` [PATCH v3 09/12] fs/resctrl: Reset kernel-mode binding when its rdtgroup goes away Babu Moger
2026-06-16 23:42   ` Reinette Chatre
2026-04-30 23:24 ` [PATCH v3 10/12] fs/resctrl: Expose kmode_cpus / kmode_cpus_list per rdtgroup Babu Moger
2026-04-30 23:24 ` [PATCH v3 11/12] resctrl: Hide kmode_cpus[_list] on groups not bound to kernel-mode Babu Moger
2026-04-30 23:24 ` [PATCH v3 12/12] fs/resctrl: Allow user space to write kmode_cpus / kmode_cpus_list Babu Moger
2026-06-11 21:53 ` [PATCH v3 00/12] [PATCH v3 00/12] x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem Reinette Chatre
2026-06-12 15:37   ` Moger, Babu
2026-06-17  4:34     ` 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=2429a51a-92ad-4810-bee9-44bd6fba3443@intel.com \
    --to=reinette.chatre@intel.com \
    --cc=Dave.Martin@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexandre.chartre@oracle.com \
    --cc=babu.moger@amd.com \
    --cc=bhelgaas@google.com \
    --cc=bp@alien8.de \
    --cc=chang.seok.bae@intel.com \
    --cc=corbet@lwn.net \
    --cc=dapeng1.mi@linux.intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=elver@google.com \
    --cc=eranian@google.com \
    --cc=feng.tang@linux.alibaba.com \
    --cc=hpa@zytor.com \
    --cc=james.morse@arm.com \
    --cc=kees@kernel.org \
    --cc=kim.phillips@amd.com \
    --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=paulmck@kernel.org \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=peternewman@google.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=seanjc@google.com \
    --cc=skhan@linuxfoundation.org \
    --cc=tglx@kernel.org \
    --cc=thomas.lendacky@amd.com \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=xin@zytor.com \
    --cc=yazen.ghannam@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox