linux-kernel - RE: [RFC PATCH 3/3] x86/resctrl: Display the RMID and COSID for resctrl groups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <IA1PR11MB609764AC3E09E0A1F8A8FF7E9BF59@IA1PR11MB6097.namprd11.prod.outlook.com>
Date:   Wed, 4 Jan 2023 06:06:31 +0000
From:   "Yu, Fenghua" <fenghua.yu@...el.com>
To:     Babu Moger <babu.moger@....com>,
        "Chatre, Reinette" <reinette.chatre@...el.com>
CC:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
        "corbet@....net" <corbet@....net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "Eranian, Stephane" <eranian@...gle.com>,
        "peternewman@...gle.com" <peternewman@...gle.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>
Subject: RE: [RFC PATCH 3/3] x86/resctrl: Display the RMID and COSID for
 resctrl groups

Hi, Babu,

> When a user creates a control or monitor group, the CLOSID or RMID are not
> visible to the user. These are architecturally defined entities.
> There is no harm in displaying these in resctrl groups. Sometimes it can help to
> debug the issues.
Although "no harm" to show them, it's not useful for generic user either and may
cause confusion sometimes. CLOSID and RMID are supposed to be invisible to
generic users.

Maybe introduce a new resctrl mount option called "debug" and show the files
and maybe other future debug info only in debug mode?

> 
> Add CLOSID and RMID to the control/monitor groups display in resctrl interface.
> 
>   $cat /sys/fs/resctrl/clos1/closid
>   1
>   $cat /sys/fs/resctrl/mon_groups/mon1/rmid
>   3
> 
> Signed-off-by: Babu Moger <babu.moger@....com>
> ---
>  Documentation/x86/resctrl.rst          |   15 ++++++++++
>  arch/x86/kernel/cpu/resctrl/rdtgroup.c |   46
> ++++++++++++++++++++++++++++++++
>  2 files changed, 61 insertions(+)
> 
> diff --git a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst
> index f26e16412bcb..8520514bc8b5 100644
> --- a/Documentation/x86/resctrl.rst
> +++ b/Documentation/x86/resctrl.rst
> @@ -231,6 +231,14 @@ All groups contain the following files:
>  	Just like "cpus", only using ranges of CPUs instead of bitmasks.
> 
> 
> +"rmid":
> +	Reading this file shows the resource monitoring id (RMID) for
> +	monitoring the resource utilization. Monitoring is performed by
> +	tagging each core(or thread) or process via a Resource Monitoring
> +	ID (RMID). Kernel assigns a new RMID when a group is created
> +	depending on the available RMIDs. Multiple cores(or threads) or
> +	processes can share a same RMID in a resctrl domain.
> +
>  When control is enabled all CTRL_MON groups will also contain:
> 
>  "schemata":
> @@ -252,6 +260,13 @@ When control is enabled all CTRL_MON groups will
> also contain:
>  	file. On successful pseudo-locked region creation the mode will
>  	automatically change to "pseudo-locked".
> 
> +"closid":
> +	Reading this file shows the Class of Service (CLOS) id which acts
> +	as a resource control tag on which the resources can be throttled.
> +	Kernel assigns a new CLOSID a control group is created depending
> +	on the available CLOSIDs. Multiple cores(or threads) or processes
> +	can share a same CLOSID in a resctrl domain.
> +
>  When monitoring is enabled all MON groups will also contain:
> 
>  "mon_data":
> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> index 0d71ed22cfa9..98b4798e5cae 100644
> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> @@ -769,6 +769,38 @@ static int rdtgroup_tasks_show(struct kernfs_open_file
> *of,
>  	return ret;
>  }
> 
> +static int rdtgroup_closid_show(struct kernfs_open_file *of,
> +				struct seq_file *s, void *v)
> +{
> +	struct rdtgroup *rdtgrp;
> +	int ret = 0;
> +
> +	rdtgrp = rdtgroup_kn_lock_live(of->kn);
> +	if (rdtgrp)
> +		seq_printf(s, "%u\n", rdtgrp->closid);
> +	else
> +		ret = -ENOENT;
> +	rdtgroup_kn_unlock(of->kn);
> +
> +	return ret;
> +}
> +
> +static int rdtgroup_rmid_show(struct kernfs_open_file *of,
> +			      struct seq_file *s, void *v)
> +{
> +	struct rdtgroup *rdtgrp;
> +	int ret = 0;
> +
> +	rdtgrp = rdtgroup_kn_lock_live(of->kn);
> +	if (rdtgrp)
> +		seq_printf(s, "%u\n", rdtgrp->mon.rmid);
> +	else
> +		ret = -ENOENT;
> +	rdtgroup_kn_unlock(of->kn);
> +
> +	return ret;
> +}
> +
>  #ifdef CONFIG_PROC_CPU_RESCTRL
> 
>  /*
> @@ -1593,6 +1625,20 @@ static struct rftype res_common_files[] = {
>  		.seq_show	= rdtgroup_size_show,
>  		.fflags		= RF_CTRL_BASE,
>  	},
> +	{
> +		.name		= "closid",
> +		.mode		= 0444,
> +		.kf_ops		= &rdtgroup_kf_single_ops,
> +		.seq_show	= rdtgroup_closid_show,
> +		.fflags		= RF_CTRL_BASE,
> +	},
> +	{
> +		.name		= "rmid",
> +		.mode		= 0444,
> +		.kf_ops		= &rdtgroup_kf_single_ops,
> +		.seq_show	= rdtgroup_rmid_show,
> +		.fflags		= RFTYPE_BASE,
> +	},
> 
>  };
> 
> 
Thanks.

-Fenghua