[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b84fee44-d52b-45c3-8664-b2215074bea9@intel.com>
Date: Thu, 19 Sep 2024 10:38:40 -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 v7 20/24] x86/resctrl: Introduce the interface to switch
between monitor modes
Hi Babu,
On 9/4/24 3:21 PM, Babu Moger wrote:
> Introduce interface to switch between mbm_cntr_assign and default modes.
>
> $ cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
> [mbm_cntr_assign]
> default
>
> To enable the "mbm_cntr_assign" mode:
> $ echo "mbm_cntr_assign" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
>
> To enable the default monitoring mode:
> $ echo "default" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
>
> MBM event counters will reset when mbm_assign_mode is changed.
>
> Signed-off-by: Babu Moger <babu.moger@....com>
> ---
> v7: Changed the interface name to mbm_assign_mode.
> Removed the references of ABMC.
> Added the changes to reset global and domain bitmaps.
> Added the changes to reset rmid.
>
> v6: Changed the mode name to mbm_cntr_assign.
> Moved all the FS related code here.
> Added changes to reset mbm_cntr_map and resctrl group counters.
> ""
> v5: Change log and mode description text correction.
>
> v4: Minor commit text changes. Keep the default to ABMC when supported.
> Fixed comments to reflect changed interface "mbm_mode".
>
> v3: New patch to address the review comments from upstream.
> ---
> Documentation/arch/x86/resctrl.rst | 15 ++++++
> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 74 +++++++++++++++++++++++++-
> 2 files changed, 88 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/arch/x86/resctrl.rst b/Documentation/arch/x86/resctrl.rst
> index ff5397d19704..743c0b64a330 100644
> --- a/Documentation/arch/x86/resctrl.rst
> +++ b/Documentation/arch/x86/resctrl.rst
> @@ -290,6 +290,21 @@ with the following files:
> than 'num_mbm_cntrs' to be created. Reading the mbm files may report 'Unavailable'
> if there is no hardware resource assigned.
>
> + * To enable ABMC feature:
The separation between fs and arch did not make it to this patch?
> + ::
> +
> + # echo "mbm_cntr_assign" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
> +
> + * To enable the legacy monitoring feature:
"legacy" -> "default"?
> + ::
> +
> + # echo "default" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
> +
> + The MBM event counters will reset when mbm_assign_mode is changed. Moving to
"will reset" -> "may reset"? Please also be clear on what is meant with "MBM event counter".
Note that "counter" has a very specific meaning in this work and after considering that
it is not clear if "MBM event counter will reset" means that the counters are no longer
assigned or if it means that the counts associated with events will be reset.
> + mbm_cntr_assign will require users to assign the counters to the events to
> + read the events. Otherwise, the MBM event counters will return "Unassigned"
> + when read.
> +
> "num_mbm_cntrs":
> The number of monitoring counters available for assignment.
>
> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> index bf94e4e05540..7a8ece12d7da 100644
> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> @@ -895,6 +895,77 @@ static int rdtgroup_mbm_assign_mode_show(struct kernfs_open_file *of,
> return 0;
> }
>
> +static void rdtgroup_mbm_cntr_reset(struct rdt_resource *r)
It is not clear why this has "rdtgroup" prefix since it is not specific to
a resource group but a global action that resets all counters.
> +{
> + struct rdtgroup *prgrp, *crgrp;
> + struct rdt_mon_domain *dom;
> +
> + /*
> + * Hardware counters will reset after switching the monitor mode.
> + * Reset the architectural state so that reading of hardware
> + * counter is not considered as an overflow in the next update.
> + * Also reset the domain counter bitmap.
> + */
> + list_for_each_entry(dom, &r->mon_domains, hdr.list) {
> + bitmap_zero(dom->mbm_cntr_map, r->mon.num_mbm_cntrs);
> + resctrl_arch_reset_rmid_all(r, dom);
> + }
> +
> + /* Reset global MBM counter map */
> + bitmap_fill(r->mon.mbm_cntr_free_map, r->mon.num_mbm_cntrs);
> +
> + /* Reset the cntr_id's for all the monitor groups */
> + list_for_each_entry(prgrp, &rdt_all_groups, rdtgroup_list) {
> + prgrp->mon.cntr_id[0] = MON_CNTR_UNSET;
> + prgrp->mon.cntr_id[1] = MON_CNTR_UNSET;
> + list_for_each_entry(crgrp, &prgrp->mon.crdtgrp_list,
> + mon.crdtgrp_list) {
> + crgrp->mon.cntr_id[0] = MON_CNTR_UNSET;
> + crgrp->mon.cntr_id[1] = MON_CNTR_UNSET;
> + }
> + }
> +}
> +
> +static ssize_t rdtgroup_mbm_assign_mode_write(struct kernfs_open_file *of,
> + char *buf, size_t nbytes, loff_t off)
> +{
> + struct rdt_resource *r = of->kn->parent->priv;
> + int ret = 0;
> + bool enable;
> +
> + /* Valid input requires a trailing newline */
> + if (nbytes == 0 || buf[nbytes - 1] != '\n')
> + return -EINVAL;
> +
> + buf[nbytes - 1] = '\0';
> +
> + cpus_read_lock();
> + mutex_lock(&rdtgroup_mutex);
> +
> + rdt_last_cmd_clear();
> +
> + if (!strcmp(buf, "default")) {
> + enable = 0;
> + } else if (!strcmp(buf, "mbm_cntr_assign")) {
> + enable = 1;
> + } else {
> + ret = -EINVAL;
> + rdt_last_cmd_puts("Unsupported assign mode\n");
> + goto write_exit;
> + }
> +
> + if (enable != resctrl_arch_mbm_cntr_assign_enabled(r)) {
> + rdtgroup_mbm_cntr_reset(r);
Should this reset not happen only after the hardware state was changed
successfully? If the arch change failed then this may lead to inconsistent
state.
> + ret = resctrl_arch_mbm_cntr_assign_set(r, enable);
> + }
> +
> +write_exit:
> + mutex_unlock(&rdtgroup_mutex);
> + cpus_read_unlock();
> +
> + return ret ?: nbytes;
> +}
> +
> static int rdtgroup_num_mbm_cntrs_show(struct kernfs_open_file *of,
> struct seq_file *s, void *v)
> {
> @@ -2107,9 +2178,10 @@ static struct rftype res_common_files[] = {
> },
> {
> .name = "mbm_assign_mode",
> - .mode = 0444,
> + .mode = 0644,
> .kf_ops = &rdtgroup_kf_single_ops,
> .seq_show = rdtgroup_mbm_assign_mode_show,
> + .write = rdtgroup_mbm_assign_mode_write,
> .fflags = RFTYPE_MON_INFO,
> },
> {
Reinette
Powered by blists - more mailing lists