[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bad25f0e-8c74-46ad-8bd0-d25f954f1714@intel.com>
Date: Fri, 12 Jul 2024 15:06:23 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: Babu Moger <babu.moger@....com>, <corbet@....net>, <fenghua.yu@...el.com>,
<tglx@...utronix.de>, <mingo@...hat.com>, <bp@...en8.de>,
<dave.hansen@...ux.intel.com>
CC: <x86@...nel.org>, <hpa@...or.com>, <paulmck@...nel.org>,
<rdunlap@...radead.org>, <tj@...nel.org>, <peterz@...radead.org>,
<yanjiewtw@...il.com>, <kim.phillips@....com>, <lukas.bulwahn@...il.com>,
<seanjc@...gle.com>, <jmattson@...gle.com>, <leitao@...ian.org>,
<jpoimboe@...nel.org>, <rick.p.edgecombe@...el.com>,
<kirill.shutemov@...ux.intel.com>, <jithu.joseph@...el.com>,
<kai.huang@...el.com>, <kan.liang@...ux.intel.com>,
<daniel.sneddon@...ux.intel.com>, <pbonzini@...hat.com>,
<sandipan.das@....com>, <ilpo.jarvinen@...ux.intel.com>,
<peternewman@...gle.com>, <maciej.wieczor-retman@...el.com>,
<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<eranian@...gle.com>, <james.morse@....com>
Subject: Re: [PATCH v5 07/20] x86/resctrl: Introduce the interface to display
monitor mode
Hi Babu,
On 7/3/24 2:48 PM, Babu Moger wrote:
> The ABMC feature provides an option to the user to assign a hardware
> counter to an RMID and monitor the bandwidth as long as it is assigned.
> ABMC mode is enabled by default when supported. System can be one mode
> at a time (Legacy monitor mode or ABMC mode).
>
> Provide an interface to display the monitor mode on the system.
> $cat /sys/fs/resctrl/info/L3_MON/mbm_mode
> [abmc]
> legacy
<insert snippet about what happens when user switches from one mode
to another>
>
> Signed-off-by: Babu Moger <babu.moger@....com>
> ---
> v5: Changed interface name to mbm_mode.
> It will be always available even if ABMC feature is not supported.
> Added description in resctrl.rst about ABMC mode.
> Fixed display abmc and legacy consistantly.
>
> v4: Fixed the checks for legacy and abmc mode. Default it ABMC.
>
> v3: New patch to display ABMC capability.
> ---
> Documentation/arch/x86/resctrl.rst | 30 ++++++++++++++++++++++++++
> arch/x86/kernel/cpu/resctrl/monitor.c | 2 ++
> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 26 ++++++++++++++++++++++
> 3 files changed, 58 insertions(+)
>
> diff --git a/Documentation/arch/x86/resctrl.rst b/Documentation/arch/x86/resctrl.rst
> index 30586728a4cd..108e494fd7cc 100644
> --- a/Documentation/arch/x86/resctrl.rst
> +++ b/Documentation/arch/x86/resctrl.rst
> @@ -257,6 +257,36 @@ with the following files:
> # cat /sys/fs/resctrl/info/L3_MON/mbm_local_bytes_config
> 0=0x30;1=0x30;3=0x15;4=0x15
>
> +"mbm_mode":
> + Reports the list of assignable monitoring features supported. The
> + enclosed brackets indicate which feature is enabled.
> + ::
> +
> + cat /sys/fs/resctrl/info/L3_MON/mbm_mode
> + [abmc]
> + legacy
> +
"mbm_cntr" mode can be documented here with the details on how AMD's ABMC is
one example of how it may be implemented on a system.
> + The bandwidth monitoring feature on AMD system only guarantees that
> + RMIDs currently assigned to a processor will be tracked by hardware.
> + The counters of any other RMIDs which are no longer being tracked
> + will be reset to zero. The MBM event counters return "Unavailable"
> + for the RMIDs that are not tracked by hardware. So, there can be
> + only limited number of groups that can give guaranteed monitoring
> + numbers. With ever changing configurations there is no way to
> + definitely know which of these groups are being tracked for certain
> + point of time. Users do not have the option to monitor a group or
> + set of groups for certain period of time without worrying about
> + RMID being reset in between.
> +
> + The ABMC feature provides an option to the user to assign a
> + hardware counter to an RMID and monitor the bandwidth as long as
> + it is assigned. The assigned RMID will be tracked by the hardware
> + until the user unassigns it manually. There is no need to worry
> + about counters being reset during this period.
> +
> + Without ABMC enabled, monitoring will work in "legacy" mode
> + without assignment option.
Let "legacy" be a distinct mode, instead of an alternative to ABMC.
> +
> "max_threshold_occupancy":
> Read/write file provides the largest value (in
> bytes) at which a previously used LLC_occupancy
> diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c
> index 12793762ca24..6c4cb36b4b50 100644
> --- a/arch/x86/kernel/cpu/resctrl/monitor.c
> +++ b/arch/x86/kernel/cpu/resctrl/monitor.c
> @@ -1245,6 +1245,8 @@ int __init rdt_get_mon_l3_config(struct rdt_resource *r)
> }
> }
>
> + resctrl_file_fflags_init("mbm_mode", RFTYPE_MON_INFO);
> +
Is this special flag assignment necessary? With file always visible I think it
can just be initialized in res_common_files below with the flag already assigned?
> l3_mon_evt_init(r);
>
> r->mon_capable = true;
> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> index 471fc0dbd7c3..3988d7b86817 100644
> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> @@ -845,6 +845,26 @@ static int rdtgroup_rmid_show(struct kernfs_open_file *of,
> return ret;
> }
>
> +static int rdtgroup_mbm_mode_show(struct kernfs_open_file *of,
> + struct seq_file *s, void *v)
> +{
> + struct rdt_resource *r = of->kn->parent->priv;
> +
> + if (r->mon.abmc_capable) {
> + if (resctrl_arch_get_abmc_enabled()) {
> + seq_puts(s, "[abmc]\n");
> + seq_puts(s, "legacy\n");
> + } else {
> + seq_puts(s, "abmc\n");
> + seq_puts(s, "[legacy]\n");
> + }
> + } else {
> + seq_puts(s, "[legacy]\n");
> + }
> +
> + return 0;
> +}
> +
> #ifdef CONFIG_PROC_CPU_RESCTRL
>
> /*
> @@ -1901,6 +1921,12 @@ static struct rftype res_common_files[] = {
> .seq_show = mbm_local_bytes_config_show,
> .write = mbm_local_bytes_config_write,
> },
> + {
> + .name = "mbm_mode",
> + .mode = 0444,
> + .kf_ops = &rdtgroup_kf_single_ops,
> + .seq_show = rdtgroup_mbm_mode_show,
> + },
> {
> .name = "cpus",
> .mode = 0644,
Reinette
Powered by blists - more mailing lists