linux-kernel - Re: [PATCH v13 31/32] x86/resctrl: Add debugfs files to show telemetry aggregator status

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <30e73735-a1ee-4dcc-83d1-2217c3f0d472@intel.com>
Date: Thu, 13 Nov 2025 14:53:26 -0800
From: Reinette Chatre <reinette.chatre@...el.com>
To: Tony Luck <tony.luck@...el.com>, Fenghua Yu <fenghuay@...dia.com>, "Maciej
 Wieczor-Retman" <maciej.wieczor-retman@...el.com>, Peter Newman
	<peternewman@...gle.com>, James Morse <james.morse@....com>, Babu Moger
	<babu.moger@....com>, Drew Fustini <dfustini@...libre.com>, Dave Martin
	<Dave.Martin@....com>, Chen Yu <yu.c.chen@...el.com>
CC: <x86@...nel.org>, <linux-kernel@...r.kernel.org>,
	<patches@...ts.linux.dev>
Subject: Re: [PATCH v13 31/32] x86/resctrl: Add debugfs files to show
 telemetry aggregator status

Hi Tony,

On 10/29/25 9:21 AM, Tony Luck wrote:
> Each telemetry aggregator provides three status registers at the top
> end of MMIO space after all the per-RMID per-event counters:
> 
>   data_loss_count: This counts the number of times that this aggregator
>   failed to accumulate a counter value supplied by a CPU core.
> 
>   data_loss_timestamp: This is a "timestamp" from a free running
>   25MHz uncore timer indicating when the most recent data loss occurred.
> 
>   last_update_timestamp: Another 25MHz timestamp indicating when the
>   most recent counter update was successfully applied.
> 
> Create files in /sys/kernel/debug/resctrl/info/PERF_PKG_MON/x86_64/
> to display the value of each of these status registers for each aggregator
> in each enabled event group. The prefix for each file name describes
> the type of aggregator, which package it is located on, and an opaque
> instance number to provide a unique file name when there are multiple
> aggregators on a package.
> 
> The suffix is one of the three strings listed above. An example name is:
> 
> 	energy_pkg0_agg2_data_loss_count

Would files named like above have enough information when considering the
theoretical struct pmt_feature_group from patch #16? In that example there
are perf aggregators with two guids. As mentioned above the aggregator
instance is opaque so a user may not know which guid a file like above may
refer to.

Reinette