andikleen

pmu-tools

Python2014–2025

andikleen / pmu-tools

pmu-tools

Intel PMU profiling tools

Testing & Quality

Explore on GitHub Read Hacker News discussions

6Distinct people

11Mentions

0Explicit recommenders

2.3KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Intel PMU profiling tools

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year11 dated mentions

Observed mentions: 2014-05-13 20:11:34 UTC to 2025-08-16 23:06:03 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2014	2014-01-01 00:00:00 UTC	2015-01-01 00:00:00 UTC	2	0	2
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	1	0	1
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	2	1	1
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	1	0	1
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	0	0	0
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	1	0	1
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	1	0	1
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	1	0	1
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	1	0	1
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	1	0	1

What Hacker News says

11 sources

jauntywundrkind·Aug 16, 2025

Intel has a Performance Monitoring Unit on its core that has significant overlap. Forgetting this tool-space, but at least some of these tools can make use of that hardware: https://github.com/intel/pcm https://github.com/andikleen/pmu-tools

In Apple's new Processor Trace instrument is incredible

scottlamb·Aug 23, 2024

> 5-10% performance boost sounds huge. Wouldn't we have much larger TLBd if page walk was really this expensive? It's pretty typical for large programs to spend 15+% of their "CPU time" waiting for the TLB. [1] So larger pages really help, including changing the base 4 KiB -> 16 KiB (4x reduction in TLB pressure) and using 2 MiB huge pages (512x reduction where it works out). I've also wondered why the TLB isn't larger. > On the other hand 9% increase in memory usage also sounds huge. How did this affect memory usage that much? This is the granularity at which physical memory is assigned, and there are a lot of reasons most of a page might be wasted: * The heap allocator will typically cram many things together in a page, but it might say only use a given page for allocations in a certain size range, so not all allocations will snuggle in

Read the rest

next to each other. * Program stacks each use at least one distinct page of physical RAM because they're placed in distinct virtual address ranges with guard pages between. So if you have 1,024 threads, they used at least 4 MiB of RAM with 4 KiB pages, 16 MiB of RAM with 16 KiB pages. * Anything from the filesystem that is cached in RAM ends up in the page cache, and true to the name, it has page granularity. So caching a 1-byte file would take 4 KiB before, 16 KiB after. [1] If you have an Intel CPU, toplev is particularly nice for pointing this kind of thing out. https://github.com/andikleen/pmu-tools

In Adding 16 kb page size to Android

soulbadguy·Jul 18, 2023

I am not seeing it mentioned anywhere, but for people looking for a good starting point on "low-level" CPU performance debugging, intel's CPU top-down u-architecture method (https://www.intel.com/content/www/us/en/docs/vtune-profiler/...) is a good systematic way to understand where you CPU is speeding most of it's cycle. They also have two tools which basically implement this analysis and spit a bunch of very useful metric that are actionable and very easy to understand - Intel Vtune is a fantastic tool to start with. It's currently free to use, support most OSes and very friendly to use for beginner. - Intel pmu-tools (https://github.com/andikleen/pmu-tools) is basically command line version of Vtune.

In Gallery of Processor Cache Effects

bitcharmer·Mar 19, 2022

Toplev is a godsend (thank you Andi Kleen!). If you work with perf you'll love this. https://github.com/andikleen/pmu-tools/wiki/toplev-manual

In Linux Perf Examples

scottlamb·Oct 6, 2020

Sort of. On Linux, have you tried toplev? https://github.com/andikleen/pmu-tools It uses CPU performance counters to show things like ITLB_Misses or MEM_Bandwidth. It won't show when you're waiting for GPU/SSD/etc because those aren't visible from CPU performance counters. I'm not aware of a single tool that will do everything, unfortunately. Also, this isn't a "benchmarking suite"; it's a tool you can use to instrument whatever load you're running, which I'd say is better. It's often used to improve software but could also identify if faster RAM will help.

In DDR5 Is Coming: First 64GB DDR5-4800 Modules from SK Hynix

soulbadguy·Dec 13, 2017

ocperf is wrapper around perf provided by someone at intel. At the first run, it downloads a list of counter specific the CPU detected, pretty cool; https://github.com/andikleen/pmu-tools

In Intel 64 and IA32 Architectures Performance Monitoring Events [pdf]

nkurz·Mar 13, 2016

I made a comment directly on the blog post which I'll copy here: I've also spent a lot of time recently trying to understand how 'perf' works at a low level. I'm getting closer, but a lot of it is still pretty impenetrable. There are four main resources that I'd recommend. The first, which you've almost surely found, is the "Perf Wiki": https://perf.wiki.kernel.org/index.php/Main_Page There's not a lot there, but it's a good introduction. The second, which you might have stumbled across, is the text documentation scattered throughout the kernel source. Most are in https://github.com/torvalds/linux/tree/master/tools/perf/Doc..., but the most useful one is up one directory at https://github.com/torvalds/linux/blob/master/tools/perf/des.... The third is Andi Kleen's PMU Tools: https://github.com/andikleen/pmu-tools The 'jevents' librar

Read the rest

y within this illustrates how to use 'perf' to set up the counters while using 'rdpmc' from userspace to read them. The fourth is Vince Weaver's Unofficial Linux Perf Events Web-Page (http://web.eece.maine.edu/~vweaver/projects/perf_events/) and his associated Perf Event Testsuite (https://github.com/deater/perf_event_tests). Tests make wonderful examples. The deeper I got into it, the more I realized is that 'perf' is still evolving, and there is a lot of anger and discontent below the surface. There were (and are) competing alternatives, but 'perf' is politically in control. Much of what you read about 'perf' should be probably be viewed through the lens of "history written by the victor", and "the vanquished" may have different perspectives. --- Separately, in case anyone is already familiar with the internals, here's an aspect where I'm currently stuck. There is an "offset" field which one is supposed to add to the result read from "rdpmc", but when I do so I get strange problems: https://github.com/nkurz/pmu-tools/commit/f2ab49207d4c7b7ddd...

In How does perf work? (in which we read the Linux kernel source)

ingve·Jan 19, 2016Submission

Pmu tools: tools for profile collection and performance analysis on Intel CPUs

4 points · Open discussion

nkurz·Oct 19, 2015

It's possible, but depending on your OS and processor it might be quite difficult. There are "Uncore" performance counters for this, but the means of access has been changing from generation to generation and the software sometimes lags behind. For Linux and Haswell EP, I've had luck with likwid: https://github.com/RRZE-HPC/likwid/wiki/Haswell-EP#memory-co... You also might have luck with Andi Kleen's pmu-tools: https://github.com/andikleen/pmu-tools/blob/master/ucevent/R... I don't know for sure if Intel's VTune supports these counters, but I'd presume it would: https://software.intel.com/en-us/intel-vtune-amplifier-xe

In Memory Is Holding Up the Moore's Law Progression of Processing Power (2014)

nkurz·Aug 29, 2014

Agner Fog's guides and the Intel reference documents are the best resources that I've found: http://www.agner.org/optimize/ http://www.intel.com/content/www/us/en/processors/architectu... IACA, perf, pmu-tools, and likwid are very useful tools. https://software.intel.com/en-us/articles/intel-architecture... https://perf.wiki.kernel.org/index.php/Main_Page https://github.com/andikleen/pmu-tools https://code.google.com/p/likwid/

In Minting Money with Monero and CPU Vector Intrinsics

nkurz·May 13, 2014

I think 'perf' is probably lying to you. Although maybe it's not a lie, as your Gist does contain that line '<not supported> dTLB-misses'. Perf tries very hard to be non-CPU specific, and thus doesn't do a great job of handling the CPU specific stuff. What processor are you running this on? If Intel, you might have luck with some of the more Intel specific wrappers here: https://github.com/andikleen/pmu-tools You also might have better luck with 'likwid': https://code.google.com/p/likwid/ Here's the arguments I was giving it to check: sudo likwid -C 1 -g \ INSTR_RETIRED_ANY:FIXC0, \ CPU_CLK_UNHALTED_CORE:FIXC1,\ CPU_CLK_UNHALTED_REF:FIXC2, \ DTLB_LOAD_MISSES_WALK_COMPLETED:PMC0 \ ./bytesum 1gb_file | INSTR_RETIRED_ANY | 7.38826e+08 | | CPU_CLK_UNHAL

Read the rest

TED_CORE | 5.42765e+08 | | CPU_CLK_UNHALTED_REF | 5.42753e+08 | | DTLB_LOAD_MISSES_WALK_COMPLETED | 1.04509e+06 | sudo likwid -C 1 -g \ INSTR_RETIRED_ANY:FIXC0, \ CPU_CLK_UNHALTED_CORE:FIXC1,\ CPU_CLK_UNHALTED_REF:FIXC2, \ DTLB_LOAD_MISSES_WALK_COMPLETED:PMC0 \ ./hugepage_prefetch 1gb_file | INSTR_RETIRED_ANY | 5.79098e+08 | | CPU_CLK_UNHALTED_CORE | 2.63809e+08 | | CPU_CLK_UNHALTED_REF | 2.63809e+08 | | DTLB_LOAD_MISSES_WALK_COMPLETED | 11970 | The other main advantage of 'likwid' is that it allows you to profile just a section of the code, rather than the program as a whole. For odd political reasons, 'perf' doesn't make this possible. ps. I think your 'argc' check is off by one. Since the name of the program is in argv[0], and argc is the length of argv, you want to check 'argc != 2' to confirm that a filename has been given.

In Computers are fast