linux-kernel - Re: [PATCH v11 00/23] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <feb03d13-e82e-422a-ba5f-ff9a937aad99@intel.com>
Date: Tue, 18 Feb 2025 10:27:13 -0800
From: Reinette Chatre <reinette.chatre@...el.com>
To: "Luck, Tony" <tony.luck@...el.com>, "babu.moger@....com"
	<babu.moger@....com>, Peter Newman <peternewman@...gle.com>
CC: "Moger, Babu" <bmoger@....com>, Dave Martin <Dave.Martin@....com>,
	"corbet@....net" <corbet@....net>, "tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "x86@...nel.org"
	<x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>, "paulmck@...nel.org"
	<paulmck@...nel.org>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "thuth@...hat.com" <thuth@...hat.com>,
	"rostedt@...dmis.org" <rostedt@...dmis.org>, "xiongwei.song@...driver.com"
	<xiongwei.song@...driver.com>, "pawan.kumar.gupta@...ux.intel.com"
	<pawan.kumar.gupta@...ux.intel.com>, "daniel.sneddon@...ux.intel.com"
	<daniel.sneddon@...ux.intel.com>, "jpoimboe@...nel.org"
	<jpoimboe@...nel.org>, "perry.yuan@....com" <perry.yuan@....com>,
	"sandipan.das@....com" <sandipan.das@....com>, "Huang, Kai"
	<kai.huang@...el.com>, "Li, Xiaoyao" <xiaoyao.li@...el.com>,
	"seanjc@...gle.com" <seanjc@...gle.com>, "Li, Xin3" <xin3.li@...el.com>,
	"andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
	"ebiggers@...gle.com" <ebiggers@...gle.com>, "mario.limonciello@....com"
	<mario.limonciello@....com>, "james.morse@....com" <james.morse@....com>,
	"tan.shaopeng@...itsu.com" <tan.shaopeng@...itsu.com>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Wieczor-Retman, Maciej" <maciej.wieczor-retman@...el.com>, "Eranian,
 Stephane" <eranian@...gle.com>
Subject: Re: [PATCH v11 00/23] x86/resctrl : Support AMD Assignable Bandwidth
 Monitoring Counters (ABMC)

Hi Tony,

On 2/18/25 8:51 AM, Luck, Tony wrote:
>> Based on the discussion so far, it felt like it is not a group level
>> breakdown. It is kind of global level breakdown. I could be wrong here.
>>
>> My understanding so far, MPAM has a number of global counters. It can be
>> assigned to any domain in the system and monitor events.
>>
>> They also have a way to configure the events (read, write or both).
>>
>> Both these feature are inline with current resctrl implementation and can
>> be easily adapted.
>>
>> One thing I am not clear why MPAM implementation plans to create separate
>> files(dynamically) in /sys/fs/resctrl/info/L3_MON/ directory to read the
>> events. We already have files in each group to read the events.
>>
>> # ls -l /sys/fs/resctrl/mon_data/mon_L3_00/
>> total 0
>> -r--r--r--. 1 root root 0 Feb 17 08:16 llc_occupancy
>> -r--r--r--. 1 root root 0 Feb 17 08:16 mbm_local_bytes
>> -r--r--r--. 1 root root 0 Feb 17 08:16 mbm_total_bytes
> 
> It would be nice if the filenames here reflected the reconfigured
> events. From what I can tell on AMD with BMEC it is possible to change the
> underlying events so that local b/w is reported in the mbm_total_bytes
> file, and vice versa. Or an event like:
> 
>    6       Dirty Victims from the QOS domain to all types of memory
> 
> is counted.
> 
> Though maybe we'd need to create a lot of filenames for the 2**6
> combinations of bits.

Instead of accommodating all possible names resctrl could support
"generic" names as hinted in Dave Martin's proposal.

The complication with BMEC is that these are the underlying
mbm_local_bytes and mbm_total_bytes events on which configuration
was built. Specifically, by default and at hardware reset mbm_local_bytes
counts exactly that. The event is fixed if BMEC is not supported and
configurable if it is.

Reinette

[1] https://lore.kernel.org/lkml/Z6zeXby8ajh0ax6i@e133380.arm.com/