From: "Moger, Babu" <babu.moger@amd.com>
To: Reinette Chatre <reinette.chatre@intel.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: [RFC PATCH v3 03/17] x86/resctrl: Detect Assignable Bandwidth Monitoring feature details
Date: Mon, 6 May 2024 14:09:38 -0500 [thread overview]
Message-ID: <80b33bc6-7b70-4853-92a0-718c2d8728d3@amd.com> (raw)
In-Reply-To: <ac22b96d-c4bb-42d9-bac8-22b9e032b59e@intel.com>
Hi Reinette,
On 5/3/24 18:26, Reinette Chatre wrote:
> Hi Babu,
>
> On 3/28/2024 6:06 PM, Babu Moger wrote:
>> ABMC feature details are reported via CPUID Fn8000_0020_EBX_x5.
>> Bits Description
>> 15:0 MAX_ABMC Maximum Supported Assignable Bandwidth
>> Monitoring Counter ID + 1
>>
>> The feature details are documented in 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
>> ---
>> v3: Removed changes related to mon_features.
>> Moved rdt_cpu_has to core.c and added new function resctrl_arch_has_abmc.
>> Also moved the fields mbm_assign_capable and mbm_assign_cntrs to
>> rdt_resource. (James)
>>
>> v2: Changed the field name to mbm_assign_capable from abmc_capable.
>> ---
>> arch/x86/kernel/cpu/resctrl/core.c | 17 +++++++++++++++++
>> arch/x86/kernel/cpu/resctrl/internal.h | 1 +
>> arch/x86/kernel/cpu/resctrl/monitor.c | 3 +++
>> include/linux/resctrl.h | 12 ++++++++++++
>> 4 files changed, 33 insertions(+)
>>
>> diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
>> index 57a8c6f30dd6..bb82b392cf5d 100644
>> --- a/arch/x86/kernel/cpu/resctrl/core.c
>> +++ b/arch/x86/kernel/cpu/resctrl/core.c
>> @@ -740,6 +740,23 @@ bool __init rdt_cpu_has(int flag)
>> return ret;
>> }
>>
>> +inline bool __init resctrl_arch_has_abmc(struct rdt_resource *r)
>> +{
>> + bool ret = rdt_cpu_has(X86_FEATURE_ABMC);
>> + u32 eax, ebx, ecx, edx;
>> +
>> + if (ret) {
>> + /*
>> + * Query CPUID_Fn80000020_EBX_x05 for number of
>> + * ABMC counters
>> + */
>> + cpuid_count(0x80000020, 5, &eax, &ebx, &ecx, &edx);
>> + r->mbm_assign_cntrs = (ebx & 0xFFFF) + 1;
>> + }
>> +
>> + return ret;
>> +}
>
> It is not clear to me why this function is needed. I went back to
> read James' comment and it sounds to me as though he expected it
> to be called from non-arch code ... but this is only called
> from rdt_get_mon_l3_config() which is very much architecture specific
> and will remain in arch/x86 where rdt_cpu_has() will be accessible.
Yes. That is correct. I will revert it and move it to rdt_get_mon_l3_config.
>
>> +
>> static __init bool get_mem_config(void)
>> {
>> struct rdt_hw_resource *hw_res = &rdt_resources_all[RDT_RESOURCE_MBA];
>> diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h
>> index c99f26ebe7a6..c4ae6f3993aa 100644
>> --- a/arch/x86/kernel/cpu/resctrl/internal.h
>> +++ b/arch/x86/kernel/cpu/resctrl/internal.h
>> @@ -584,6 +584,7 @@ void free_rmid(u32 closid, u32 rmid);
>> int rdt_get_mon_l3_config(struct rdt_resource *r);
>> void __exit rdt_put_mon_l3_config(void);
>> bool __init rdt_cpu_has(int flag);
>> +bool __init resctrl_arch_has_abmc(struct rdt_resource *r);
>> void mon_event_count(void *info);
>> int rdtgroup_mondata_show(struct seq_file *m, void *arg);
>> void mon_event_read(struct rmid_read *rr, struct rdt_resource *r,
>> diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c
>> index c34a35ec0f03..e5938bf53d5a 100644
>> --- a/arch/x86/kernel/cpu/resctrl/monitor.c
>> +++ b/arch/x86/kernel/cpu/resctrl/monitor.c
>> @@ -1055,6 +1055,9 @@ int __init rdt_get_mon_l3_config(struct rdt_resource *r)
>> mbm_local_event.configurable = true;
>> mbm_config_rftype_init("mbm_local_bytes_config");
>> }
>> +
>> + if (resctrl_arch_has_abmc(r))
>> + r->mbm_assign_capable = ABMC_ASSIGN;
>> }
>
> This is confusing to me in two ways:
> (a) why need different layers of abstraction to initialize r->mbm_assign_capable
> and r->mbm_assign_cntrs? Can they not just be assigned at the same time?
Yes. we can.
> (b) r->mbm_assign_capable is a bool ... but it is assigned an enum? Why is
> this enum needed for this?
Enum is really not required. Will correct it.
>
>>
>> l3_mon_evt_init(r);
>> diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
>> index a365f67131ec..a1ee9afabff3 100644
>> --- a/include/linux/resctrl.h
>> +++ b/include/linux/resctrl.h
>> @@ -150,6 +150,14 @@ struct resctrl_membw {
>> struct rdt_parse_data;
>> struct resctrl_schema;
>>
>> +/**
>> + * enum mbm_assign_type - The type of assignable monitoring.
>> + * @ABMC_ASSIGN: Assignable Bandwidth Monitoring Counters.
>> + */
>> +enum mbm_assign_type {
>> + ABMC_ASSIGN = 0x01,
>> +};
>> +
>
> Either the resource is mbm_assign_capable or not ... it is not clear
> to me why an enum is needed.
This is not required.
>
>> /**
>> * struct rdt_resource - attributes of a resctrl resource
>> * @rid: The index of the resource
>> @@ -168,6 +176,8 @@ struct resctrl_schema;
>> * @evt_list: List of monitoring events
>> * @fflags: flags to choose base and info files
>> * @cdp_capable: Is the CDP feature available on this resource
>> + * @mbm_assign_capable: Does system capable of supporting monitor assignment?
>
> "Does system capable" -> "Is system capable"?
Sure.
>
>> + * @mbm_assign_cntrs: Maximum number of assignable counters
>> */
>> struct rdt_resource {
>> int rid;
>> @@ -188,6 +198,8 @@ struct rdt_resource {
>> struct list_head evt_list;
>> unsigned long fflags;
>> bool cdp_capable;
>> + bool mbm_assign_capable;
>> + u32 mbm_assign_cntrs;
>> };
>
> Please check tabs vs spaces (in this whole series please).
Sure. Will do.
>
> I'm thinking that a new "MBM specific" struct within
> struct rdt_resource will be helpful to clearly separate the MBM related
> data. This will be similar to struct resctrl_cache for
> cache allocation and struct resctrl_membw for memory bandwidth
> allocation.
Did you mean to move all the fields for monitoring to move to new struct?
Struct resctrl_mbm {
int num_rmid;
bool mbm_assign_capable;
u32 mbm_assign_cntrs;
}:
--
Thanks
Babu Moger
next prev parent reply other threads:[~2024-05-06 19:09 UTC|newest]
Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-29 1:06 [RFC PATCH v3 00/17] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC) Babu Moger
2024-03-29 1:06 ` [RFC PATCH v3 01/17] x86/resctrl: Add support for " Babu Moger
2024-05-03 23:25 ` Reinette Chatre
2024-05-06 17:57 ` Moger, Babu
2024-03-29 1:06 ` [RFC PATCH v3 02/17] x86/resctrl: Add ABMC feature in the command line options Babu Moger
2024-03-29 1:06 ` [RFC PATCH v3 03/17] x86/resctrl: Detect Assignable Bandwidth Monitoring feature details Babu Moger
2024-05-03 23:26 ` Reinette Chatre
2024-05-06 19:09 ` Moger, Babu [this message]
2024-05-07 20:27 ` Reinette Chatre
2024-05-09 22:34 ` Moger, Babu
2024-05-10 3:18 ` Reinette Chatre
2024-05-10 17:01 ` Moger, Babu
2024-05-10 18:34 ` Reinette Chatre
2024-05-11 1:40 ` Moger, Babu
2024-03-29 1:06 ` [RFC PATCH v3 04/17] x86/resctrl: Introduce resctrl_file_fflags_init Babu Moger
2024-05-03 23:26 ` Reinette Chatre
2024-05-06 20:23 ` Moger, Babu
2024-05-07 20:27 ` Reinette Chatre
2024-05-10 0:23 ` Moger, Babu
2024-03-29 1:06 ` [RFC PATCH v3 05/17] x86/resctrl: Introduce the interface to display the assignment state Babu Moger
2024-05-03 23:28 ` Reinette Chatre
2024-05-07 16:28 ` Moger, Babu
2024-05-07 20:32 ` Reinette Chatre
2024-03-29 1:06 ` [RFC PATCH v3 06/17] x86/resctrl: Introduce interface to display number of ABMC counters Babu Moger
2024-03-29 1:06 ` [RFC PATCH v3 07/17] x86/resctrl: Add support to enable/disable ABMC feature Babu Moger
2024-04-04 0:30 ` Peter Newman
2024-04-04 15:16 ` Moger, Babu
2024-04-04 17:36 ` Peter Newman
2024-04-04 18:35 ` Moger, Babu
2024-04-04 18:43 ` Reinette Chatre
2024-04-04 19:01 ` Peter Newman
2024-05-16 20:03 ` Moger, Babu
2024-05-03 23:30 ` Reinette Chatre
2024-05-07 19:12 ` Moger, Babu
2024-05-07 20:32 ` Reinette Chatre
2024-05-09 21:45 ` Moger, Babu
2024-03-29 1:06 ` [RFC PATCH v3 08/17] x86/resctrl: Initialize assignable counters bitmap Babu Moger
2024-05-03 23:31 ` Reinette Chatre
2024-05-07 20:03 ` Moger, Babu
2024-03-29 1:06 ` [RFC PATCH v3 09/17] x86/resctrl: Introduce assign state for the mon group Babu Moger
2024-04-16 18:52 ` Peter Newman
2024-04-16 19:52 ` Moger, Babu
2024-03-29 1:06 ` [RFC PATCH v3 10/17] x86/resctrl: Add data structures for ABMC assignment Babu Moger
2024-05-03 23:32 ` Reinette Chatre
2024-05-07 20:40 ` Moger, Babu
2024-05-07 23:06 ` Reinette Chatre
2024-05-10 0:28 ` Moger, Babu
2024-03-29 1:06 ` [RFC PATCH v3 11/17] x86/resctrl: Introduce mbm_total_cfg and mbm_local_cfg Babu Moger
2024-05-03 23:33 ` Reinette Chatre
2024-05-08 15:57 ` Moger, Babu
2024-03-29 1:06 ` [RFC PATCH v3 12/17] x86/resctrl: Add the functionality to assign the RMID Babu Moger
2024-05-03 23:33 ` Reinette Chatre
2024-05-08 17:40 ` Moger, Babu
2024-03-29 1:06 ` [RFC PATCH v3 13/17] x86/resctrl: Add the functionality to unassign " Babu Moger
2024-03-29 1:06 ` [RFC PATCH v3 14/17] x86/resctrl: Enable ABMC by default on resctrl mount Babu Moger
2024-03-29 1:06 ` [RFC PATCH v3 15/17] x86/resctrl: Introduce the interface switch between ABMC and legacy_mbm Babu Moger
2024-03-29 1:06 ` [RFC PATCH v3 16/17] x86/resctrl: Introduce interface to list assignment states of all the groups Babu Moger
2024-03-29 1:06 ` [RFC PATCH v3 17/17] x86/resctrl: Introduce interface to modify assignment states of " Babu Moger
2024-04-17 17:45 ` Peter Newman
2024-04-17 19:39 ` Moger, Babu
2024-04-17 20:56 ` Peter Newman
2024-04-17 22:52 ` Moger, Babu
2024-05-02 23:00 ` Reinette Chatre
2024-05-03 16:14 ` Moger, Babu
2024-05-03 21:16 ` Reinette Chatre
2024-05-06 18:09 ` Moger, Babu
2024-05-02 16:21 ` Dave Martin
2024-05-02 17:52 ` Reinette Chatre
2024-05-02 18:11 ` Moger, Babu
2024-05-03 14:53 ` Dave Martin
2024-05-03 21:15 ` Reinette Chatre
2024-04-04 19:08 ` [RFC PATCH v3 00/17] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC) Peter Newman
2024-04-04 20:02 ` Moger, Babu
2024-04-22 16:34 ` Dave Martin
2024-04-22 20:44 ` Moger, Babu
2024-04-23 12:37 ` Dave Martin
2024-04-24 4:15 ` Reinette Chatre
2024-04-24 14:16 ` Dave Martin
2024-04-24 19:10 ` Moger, Babu
2024-04-22 16:33 ` Dave Martin
2024-04-22 18:23 ` Peter Newman
2024-04-23 12:38 ` Dave Martin
2024-04-23 15:43 ` Moger, Babu
2024-04-23 16:17 ` Dave Martin
2024-05-01 17:48 ` Peter Newman
2024-05-02 16:25 ` Moger, Babu
2024-05-02 17:50 ` Peter Newman
2024-05-02 20:14 ` Moger, Babu
2024-05-02 23:21 ` Reinette Chatre
2024-05-03 0:57 ` Peter Newman
2024-05-03 20:44 ` Moger, Babu
2024-05-03 21:00 ` Peter Newman
2024-05-03 21:15 ` Reinette Chatre
2024-05-17 21:51 ` Peter Newman
2024-05-20 14:25 ` Moger, Babu
2024-05-20 16:00 ` Peter Newman
2024-05-20 18:03 ` Moger, Babu
2024-05-10 0:57 ` Moger, Babu
2024-05-10 2:47 ` Reinette Chatre
2024-05-03 21:14 ` Reinette Chatre
2024-05-03 23:24 ` Reinette Chatre
2024-05-06 17:18 ` Moger, Babu
2024-05-07 20:26 ` Reinette Chatre
2024-05-08 20:07 ` Moger, Babu
2024-05-08 20:41 ` Reinette Chatre
2024-05-08 23:29 ` Moger, Babu
2024-05-09 18:07 ` Reinette Chatre
2024-05-09 20:34 ` 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=80b33bc6-7b70-4853-92a0-718c2d8728d3@amd.com \
--to=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=reinette.chatre@intel.com \
--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
all inboxes | Powered by JetHome®