[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e45064ca-56f5-4d86-b088-cd24ffc0e96d@amd.com>
Date: Tue, 15 Jul 2025 09:16:52 -0500
From: "Moger, Babu" <babu.moger@....com>
To: Peter Newman <peternewman@...gle.com>
Cc: corbet@....net, tony.luck@...el.com, reinette.chatre@...el.com,
james.morse@....com, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, Dave.Martin@....com, x86@...nel.org,
hpa@...or.com, akpm@...ux-foundation.org, paulmck@...nel.org,
rostedt@...dmis.org, Neeraj.Upadhyay@....com, david@...hat.com,
arnd@...db.de, fvdl@...gle.com, seanjc@...gle.com, jpoimboe@...nel.org,
pawan.kumar.gupta@...ux.intel.com, xin@...or.com, manali.shukla@....com,
tao1.su@...ux.intel.com, sohil.mehta@...el.com, kai.huang@...el.com,
xiaoyao.li@...el.com, peterz@...radead.org, xin3.li@...el.com,
kan.liang@...ux.intel.com, mario.limonciello@....com,
thomas.lendacky@....com, perry.yuan@....com, gautham.shenoy@....com,
chang.seok.bae@...el.com, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, eranian@...gle.com
Subject: Re: [PATCH v15 05/34] x86/cpufeatures: Add support for Assignable
Bandwidth Monitoring Counters (ABMC)
Hi Peter,
On 7/15/25 06:47, Peter Newman wrote:
> Hi Babu,
>
> On Wed, Jul 9, 2025 at 12:18 AM Babu Moger <babu.moger@....com> wrote:
>>
>> Users can create as many monitor groups as RMIDs supported by the hardware.
>> However, 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 during a particular time. Users do not have the option to
>> monitor a group or set of groups for a certain period of time without
>> worrying about RMID being reset in between.
>>
>> The ABMC feature allows users to assign a hardware counter to an RMID,
>> event pair and monitor bandwidth usage as long as it is assigned. The
>> hardware continues to track the assigned counter until it is explicitly
>> unassigned by the user. There is no need to worry about counters being
>> reset during this period. Additionally, the user can specify the type of
>> memory transactions (e.g., reads, writes) for the counter to track.
>>
>> Without ABMC enabled, monitoring will work in current mode without
>> assignment option.
>>
>> The Linux resctrl subsystem provides an interface that allows monitoring of
>> up to two memory bandwidth events per group, selected from a combination of
>> available total and local events. When ABMC is enabled, two events will be
>> assigned to each group by default, in line with the current interface
>> design. Users will also have the option to configure which types of memory
>> transactions are counted by these events.
>>
>> Due to the limited number of available counters (32), users may quickly
>> exhaust the available counters. If the system runs out of assignable ABMC
>> counters, the kernel will report an error. In such cases, users will need
>> to unassign one or more active counters to free up counters for new
>> assignments. resctrl will provide options to assign or unassign events
>> through the group-specific interface file.
>>
>> The feature is detected via CPUID_Fn80000020_EBX_x00 bit 5.
>> Bits Description
>> 5 ABMC (Assignable Bandwidth Monitoring Counters)
>>
>> 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).
>>
>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
>> Signed-off-by: Babu Moger <babu.moger@....com>
>> ---
>> Note: Checkpatch checks/warnings are ignored to maintain coding style.
>>
>> v15: Minor changelog update.
>>
>> v14: Removed the dependancy on X86_FEATURE_CQM_MBM_TOTAL and X86_FEATURE_CQM_MBM_LOCAL.
>> as discussed in https://lore.kernel.org/lkml/5f8b21c6-5166-46a6-be14-0c7c9bfb7cde@intel.com/
>> Need to re-work on ABMC enumeration during the init.
>> Updated changelog with few text update.
>>
>> v13: Updated the commit log with Linux interface details.
>>
>> v12: Removed the dependancy on X86_FEATURE_BMEC.
>> Removed the Reviewed-by tag as patch has changed.
>>
>> v11: No changes.
>>
>> v10: No changes.
>>
>> v9: Took care of couple of minor merge conflicts. No other changes.
>>
>> v8: No changes.
>>
>> v7: Removed "" from feature flags. Not required anymore.
>> https://lore.kernel.org/lkml/20240817145058.GCZsC40neU4wkPXeVR@fat_crate.local/
>>
>> v6: Added Reinette's Reviewed-by. Moved the Checkpatch note below ---.
>>
>> v5: Minor rebase change and subject line update.
>>
>> v4: Changes because of rebase. Feature word 21 has few more additions now.
>> Changed the text to "tracked by hardware" instead of active.
>>
>> v3: Change because of rebase. Actual patch did not change.
>>
>> v2: Added dependency on X86_FEATURE_BMEC.
>> ---
>> arch/x86/include/asm/cpufeatures.h | 1 +
>> arch/x86/kernel/cpu/scattered.c | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
>> index b78af55aa22e..d2950a0177cd 100644
>> --- a/arch/x86/include/asm/cpufeatures.h
>> +++ b/arch/x86/include/asm/cpufeatures.h
>> @@ -490,6 +490,7 @@
>> #define X86_FEATURE_PREFER_YMM (21*32+ 8) /* Avoid ZMM registers due to downclocking */
>> #define X86_FEATURE_APX (21*32+ 9) /* Advanced Performance Extensions */
>> #define X86_FEATURE_INDIRECT_THUNK_ITS (21*32+10) /* Use thunk for indirect branches in lower half of cacheline */
>> +#define X86_FEATURE_ABMC (21*32+11) /* Assignable Bandwidth Monitoring Counters */
>
> It looks like this bit has been taken by X86_FEATURE_TSA_SQ_NO. I had
> to move X86_FEATURE_ABMC down to (21*32+14) on tip/master.
>
Yea. Thats right. Will take care in next revision.
--
Thanks
Babu Moger
Powered by blists - more mailing lists