From: Reinette Chatre <reinette.chatre@intel.com>
To: Babu Moger <babu.moger@amd.com>, <corbet@lwn.net>,
<fenghua.yu@intel.com>, <tglx@linutronix.de>, <mingo@redhat.com>,
<bp@alien8.de>, <dave.hansen@linux.intel.com>
Cc: <x86@kernel.org>, <hpa@zytor.com>, <paulmck@kernel.org>,
<rdunlap@infradead.org>, <tj@kernel.org>, <peterz@infradead.org>,
<yanjiewtw@gmail.com>, <kim.phillips@amd.com>,
<lukas.bulwahn@gmail.com>, <seanjc@google.com>,
<jmattson@google.com>, <leitao@debian.org>, <jpoimboe@kernel.org>,
<rick.p.edgecombe@intel.com>, <kirill.shutemov@linux.intel.com>,
<jithu.joseph@intel.com>, <kai.huang@intel.com>,
<kan.liang@linux.intel.com>, <daniel.sneddon@linux.intel.com>,
<pbonzini@redhat.com>, <sandipan.das@amd.com>,
<ilpo.jarvinen@linux.intel.com>, <peternewman@google.com>,
<maciej.wieczor-retman@intel.com>, <linux-doc@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <eranian@google.com>,
<james.morse@arm.com>
Subject: Re: [PATCH v4 14/19] x86/resctrl: Add the interface to assign ABMC counter
Date: Thu, 13 Jun 2024 18:48:28 -0700 [thread overview]
Message-ID: <e649a49f-344f-4dbd-be2f-d70f932a80f4@intel.com> (raw)
In-Reply-To: <631092558e7fe0ac2e6267070e40c4a97b300f57.1716552602.git.babu.moger@amd.com>
Hi Babu,
On 5/24/24 5:23 AM, Babu Moger wrote:
> ABMC feature requires to users to assign a hardware counter to an RMID
"requires to users" -> "requires users"?
> to monitor the events. Provide the interfaces to assign a counter.
>
> Individual counters are configured by writing to L3_QOS_ABMC_CFG MSR
> and specifying the counter id, bandwidth source, and bandwidth types.
Where is discription of what this patch does and why?
This and following patches seem to introduce building blocks that
are only used later in series. These building blocks are introduced
without any information about what they do and why and that makes it
difficult to understand how this work will fall into place.
>
> The feature details are documented in the APM listed below [1].
> [1] AMD64 Architecture Programmer's Manual Volume 2: System Programming
> Publication # 24593 Revision 3.41 section 19.3.3.3 Assignable Bandwidth
> Monitoring (ABMC).
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
> ---
> v4: Commit message update.
> User bitmap APIs where applicable.
> Changed the interfaces considering MPAM(arm).
> Added domain specific assignment.
>
> v3: Removed the static from the prototype of rdtgroup_assign_abmc.
> The function is not called directly from user anymore. These
> changes are related to global assignment interface.
>
> v2: Minor text changes in commit message.
> ---
> arch/x86/kernel/cpu/resctrl/internal.h | 3 +
> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 101 +++++++++++++++++++++++++
> 2 files changed, 104 insertions(+)
>
> diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h
> index 45ed33f4f0ff..a88c8fc5e4df 100644
> --- a/arch/x86/kernel/cpu/resctrl/internal.h
> +++ b/arch/x86/kernel/cpu/resctrl/internal.h
> @@ -657,6 +657,9 @@ void rdt_domain_reconfigure_cdp(struct rdt_resource *r);
> void __init resctrl_file_fflags_init(const char *config,
> unsigned long fflags);
> void arch_domain_mbm_evt_config(struct rdt_hw_domain *hw_dom);
> +int resctrl_arch_assign(struct rdt_domain *d, u32 evtid, u32 rmid,
> + u32 ctr_id, u32 closid, bool enable);
> +int resctrl_grp_assign(struct rdtgroup *rdtgrp, u32 evtid);
> void rdt_staged_configs_clear(void);
> bool closid_allocated(unsigned int closid);
> int resctrl_find_cleanest_closid(void);
> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> index 0e425c91fa46..48df76499a04 100644
> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> @@ -203,6 +203,19 @@ static void num_cntrs_init(void)
> num_cntrs_free_map_len = r->mon.num_cntrs;
> }
>
> +static int assign_cntrs_alloc(void)
Only one counter is allocated and "assign" is unexpected since it
seems to imply how this counter will be used.
It can just be "mon_cntr_alloc()"?
> +{
> + u32 ctr_id = find_first_bit(&num_cntrs_free_map,
> + num_cntrs_free_map_len);
> +
> + if (ctr_id >= num_cntrs_free_map_len)
> + return -ENOSPC;
> +
> + __clear_bit(ctr_id, &num_cntrs_free_map);
> +
> + return ctr_id;
> +}
> +
> /**
> * rdtgroup_mode_by_closid - Return mode of resource group with closid
> * @closid: closid if the resource group
> @@ -1830,6 +1843,94 @@ static ssize_t mbm_local_bytes_config_write(struct kernfs_open_file *of,
> return ret ?: nbytes;
> }
>
> +static void rdtgroup_abmc_cfg(void *info)
> +{
> + u64 *msrval = info;
> +
> + wrmsrl(MSR_IA32_L3_QOS_ABMC_CFG, *msrval);
> +}
> +
Please add comments to these functions to summarize what
they do.
> +int resctrl_arch_assign(struct rdt_domain *d, u32 evtid, u32 rmid,
> + u32 ctr_id, u32 closid, bool enable)
> +{
> + struct rdt_hw_domain *hw_dom = resctrl_to_arch_dom(d);
> + union l3_qos_abmc_cfg abmc_cfg = { 0 };
> + struct arch_mbm_state *arch_mbm;
> +
> + abmc_cfg.split.cfg_en = 1;
> + abmc_cfg.split.ctr_en = enable ? 1 : 0;
> + abmc_cfg.split.ctr_id = ctr_id;
> + abmc_cfg.split.bw_src = rmid;
> +
> + /*
> + * Read the event configuration from the domain and pass it as
> + * bw_type.
> + */
> + if (evtid == QOS_L3_MBM_TOTAL_EVENT_ID) {
> + abmc_cfg.split.bw_type = hw_dom->mbm_total_cfg;
> + arch_mbm = &hw_dom->arch_mbm_total[rmid];
> + } else {
> + abmc_cfg.split.bw_type = hw_dom->mbm_local_cfg;
> + arch_mbm = &hw_dom->arch_mbm_local[rmid];
> + }
> +
> + smp_call_function_any(&d->cpu_mask, rdtgroup_abmc_cfg, &abmc_cfg, 1);
> +
> + /* Reset the internal counters */
"internal counters"? This needs a definition ... but since this is not
a new data structure the comment can be more specific about what is done
and why.
> + if (arch_mbm)
> + memset(arch_mbm, 0, sizeof(struct arch_mbm_state));
> +
> + return 0;
If this function always succeeds then it can just be void?
> +}
> +
> +int resctrl_grp_assign(struct rdtgroup *rdtgrp, u32 evtid)
Please use consistent naming. Note how the filename is "rdtgroup.c" and this
function operates on "struct rdtgroup" and if you take a closer look at
the functions in this file and the header where you add this function you
will notice a distinct pattern of "rdtgroup_" used as prefix. There really
is no reason to start a new namespace for this.
> +{
> + struct rdt_resource *r = &rdt_resources_all[RDT_RESOURCE_L3].r_resctrl;
> + int ctr_id = 0, index;
> + struct rdt_domain *d;
> + u32 mon_state;
> +
> + index = mon_event_config_index_get(evtid);
> + if (index == INVALID_CONFIG_INDEX) {
> + rdt_last_cmd_puts("Invalid event id\n");
> + return -EINVAL;
> + }
> +
> + if (evtid == QOS_L3_MBM_TOTAL_EVENT_ID) {
> + mon_state = ASSIGN_TOTAL;
> + } else if (evtid == QOS_L3_MBM_LOCAL_EVENT_ID) {
> + mon_state = ASSIGN_LOCAL;
> + } else {
> + rdt_last_cmd_puts("Invalid event id\n");
> + return -EINVAL;
> + }
> +
> + /* Nothing to do if event has been assigned already */
> + if (rdtgrp->mon.mon_state & mon_state) {
Why is this mon_state needed? Is it not redundant when considering that
struct mongroup has an array of counter IDs that can already be used
to see if a counter is assigned or not?
What if there is a new:
#define MON_CNTR_UNSET U32_MAX
When cntr_id[index] == MON_CNTR_UNSET then it is not assigned.
> + rdt_last_cmd_puts("ABMC counter is assigned already\n");
> + return 0;
> + }
> +
> + /*
> + * Allocate a new counter and update domains
> + */
> + ctr_id = assign_cntrs_alloc();
> + if (ctr_id < 0) {
> + rdt_last_cmd_puts("Out of ABMC counters\n");
> + return -ENOSPC;
> + }
> +
> + rdtgrp->mon.ctr_id[index] = ctr_id;
> +
> + list_for_each_entry(d, &r->domains, list)
> + resctrl_arch_assign(d, evtid, rdtgrp->mon.rmid, ctr_id,
> + rdtgrp->closid, 1);
> +
> + rdtgrp->mon.mon_state |= mon_state;
> +
> + return 0;
> +}
> +
> /* rdtgroup information files for one cache resource. */
> static struct rftype res_common_files[] = {
> {
Reinette
next prev parent reply other threads:[~2024-06-14 1:48 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-24 12:23 [PATCH v4 00/19] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC) Babu Moger
2024-05-24 12:23 ` [PATCH v4 01/19] x86/resctrl: Add support for " Babu Moger
2024-06-14 0:54 ` Reinette Chatre
2024-06-18 21:02 ` Moger, Babu
2024-05-24 12:23 ` [PATCH v4 02/19] x86/resctrl: Add ABMC feature in the command line options Babu Moger
2024-05-24 12:23 ` [PATCH v4 03/19] x86/resctrl: Consolidate monitoring related data from rdt_resource Babu Moger
2024-06-14 0:55 ` Reinette Chatre
2024-06-18 21:02 ` Moger, Babu
2024-05-24 12:23 ` [PATCH v4 04/19] x86/resctrl: Detect Assignable Bandwidth Monitoring feature details Babu Moger
2024-06-14 0:56 ` Reinette Chatre
2024-06-18 21:03 ` Moger, Babu
2024-05-24 12:23 ` [PATCH v4 05/19] x86/resctrl: Introduce resctrl_file_fflags_init to initialize fflags Babu Moger
2024-06-14 0:57 ` Reinette Chatre
2024-06-18 21:03 ` Moger, Babu
2024-05-24 12:23 ` [PATCH v4 06/19] x86/resctrl: Introduce interface to display number of ABMC counters Babu Moger
2024-06-14 0:57 ` Reinette Chatre
2024-06-18 21:04 ` Moger, Babu
2024-05-24 12:23 ` [PATCH v4 07/19] x86/resctrl: Add support to enable/disable ABMC feature Babu Moger
2024-06-14 0:59 ` Reinette Chatre
2024-06-19 15:37 ` Moger, Babu
2024-06-20 22:02 ` Reinette Chatre
2024-06-21 15:44 ` Moger, Babu
2024-05-24 12:23 ` [PATCH v4 08/19] x86/resctrl: Introduce the interface to display monitor mode Babu Moger
2024-06-14 1:40 ` Reinette Chatre
2024-06-19 16:25 ` Moger, Babu
2024-06-20 22:05 ` Reinette Chatre
2024-06-21 15:47 ` Moger, Babu
2024-05-24 12:23 ` [PATCH v4 09/19] x86/resctrl: Initialize ABMC counters bitmap Babu Moger
2024-06-14 1:42 ` Reinette Chatre
2024-06-19 17:03 ` Moger, Babu
2024-06-20 22:20 ` Reinette Chatre
2024-06-21 16:01 ` Moger, Babu
2024-05-24 12:23 ` [PATCH v4 10/19] x86/resctrl: Introduce ABMC state for the monitor group Babu Moger
2024-05-24 12:23 ` [PATCH v4 11/19] x86/resctrl: Introduce mbm_total_cfg and mbm_local_cfg Babu Moger
2024-06-14 1:43 ` Reinette Chatre
2024-06-19 18:46 ` Moger, Babu
2024-06-27 18:51 ` Moger, Babu
2024-06-27 20:56 ` Reinette Chatre
2024-06-27 21:26 ` Moger, Babu
2024-05-24 12:23 ` [PATCH v4 12/19] x86/resctrl: Remove MSR reading of event configuration value Babu Moger
2024-05-24 12:23 ` [PATCH v4 13/19] x86/resctrl: Add data structures for ABMC assignment Babu Moger
2024-06-14 1:44 ` Reinette Chatre
2024-06-19 20:10 ` Moger, Babu
2024-05-24 12:23 ` [PATCH v4 14/19] x86/resctrl: Add the interface to assign ABMC counter Babu Moger
2024-06-14 1:48 ` Reinette Chatre [this message]
2024-06-19 22:38 ` Moger, Babu
2024-06-20 22:50 ` Reinette Chatre
2024-06-21 16:07 ` Moger, Babu
2024-05-24 12:23 ` [PATCH v4 15/19] x86/resctrl: Add the interface to unassign " Babu Moger
2024-06-14 1:49 ` Reinette Chatre
2024-06-20 13:48 ` Moger, Babu
2024-05-24 12:23 ` [PATCH v4 16/19] x86/resctrl: Enable ABMC by default on resctrl mount Babu Moger
2024-06-14 1:50 ` Reinette Chatre
2024-06-20 14:46 ` Moger, Babu
2024-06-20 22:49 ` Reinette Chatre
2024-06-21 16:29 ` Moger, Babu
2024-05-24 12:23 ` [PATCH v4 17/19] x86/resctrl: Introduce the interface switch between ABMC and mbm_legacy Babu Moger
2024-06-14 1:51 ` Reinette Chatre
2024-06-20 14:53 ` Moger, Babu
2024-06-21 14:43 ` Markus Elfring
2024-05-24 12:23 ` [PATCH v4 18/19] x86/resctrl: Introduce interface to list monitor states of all the groups Babu Moger
2024-05-24 12:23 ` [PATCH v4 19/19] x86/resctrl: Introduce interface to modify assignment states of " Babu Moger
2024-06-14 0:54 ` [PATCH v4 00/19] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC) Reinette Chatre
2024-06-18 21:02 ` Moger, Babu
2024-06-20 22:49 ` Reinette Chatre
2024-06-21 16:41 ` Moger, Babu
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=e649a49f-344f-4dbd-be2f-d70f932a80f4@intel.com \
--to=reinette.chatre@intel.com \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=daniel.sneddon@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=eranian@google.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=james.morse@arm.com \
--cc=jithu.joseph@intel.com \
--cc=jmattson@google.com \
--cc=jpoimboe@kernel.org \
--cc=kai.huang@intel.com \
--cc=kan.liang@linux.intel.com \
--cc=kim.phillips@amd.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=leitao@debian.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas.bulwahn@gmail.com \
--cc=maciej.wieczor-retman@intel.com \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peternewman@google.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=sandipan.das@amd.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=x86@kernel.org \
--cc=yanjiewtw@gmail.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;
as well as URLs for NNTP newsgroup(s).