Details

Reviewers

imp
jhb
mhorne
adrian

Group Reviewers

pmc

Commits

rGa79a051e7d16: pmc: pmc record command

Summary

The record command is designed around the idea of predefined studies.
While you can still select individual counters, the predefined studies
are meant to enable the best hardware options for a given generation.
It implements all of the base studies that I have built so far.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

ali_mashtizadeh.com requested review of this revision.Jun 23 2026, 4:26 PM

ali_mashtizadeh.com created this revision.

Harbormaster completed remote builds in B74155: Diff 180401.Jun 23 2026, 4:26 PM

ali_mashtizadeh.com added a parent revision: D57776: pmc: new pmc log processing framework.Jun 23 2026, 4:27 PM

ali_mashtizadeh.com added a child revision: D57778: pmc: pmc info command.

mhorne added a reviewer: pmc.Jun 30 2026, 3:15 PM

adrian added a subscriber: adrian.Jun 30 2026, 5:40 PM

adrian added inline comments.

usr.sbin/pmc/cmd_pmc_record.cc
107	Does this hold for all CPUs? eg do CPU threads have the same counters, or are there counters that are shared between CPU threads on a core that can't be allocated per thread? I'm pretty sure I faced this on power8/power9 with their core/thread counter hierarchy.
290	no armv7 ?
429	heh, do you have plans to add the other CPU types to the cpuinfo dump?
503	are there plans to figure out how to extend libpmc to have some better defaults for stuff like this? (eg maybe having libpmc know about "default" and "flamegraph" configs to use, and that be an API contract?)

Thanks Adrian for your comments if there's anything you want me to urgently fix I can do that. Otherwise my goal was get the general and IBS tooling in people's hands.

usr.sbin/pmc/cmd_pmc_record.cc
107	Yes, this is copying the existing logic and I agree it's not right. We will have a problem with AMD Zen 6 that introduces the notion of nodes (overloaded term and no they don't match chiplets it's like IO die nodes). So I need upstream a patch I wrote to expose a get cpumask operation, but we need to combine that with the counter's metadata in some platforms.
429	Yes, I can take care of ARM and POWER soon, but haven't had a chance to test on those recently.
503	are there plans to figure out how to extend libpmc to have some better defaults for stuff like this? (eg maybe having libpmc know about "default" and "flamegraph" configs to use, and that be an API contract?) Unfortunately the aliases such as instructions haven't been maintained and are pretty ugly inside of libpmc. I had an alternative plan to move things into a set of configuration files. IBS is somewhat of a special case. When I introduce the some future bits for supporting printing counters, e.g. the top-down model. I will move the aliasing and other stuff into a set of files that we place into /usr/share (or /usr/local/share for privately distributed files).
512	I'll refresh this it's supposed too be changed to unhalted cycles.

Thanks for your comments I fixed the armv7 and cleaned up the default/flamegraph to use unhalted-cycles. Seems that is defined now on x86 and ARM64 correctly, but I'll make a separate patch to add reasonable aliases for POWER8/9.

usr.sbin/pmc/cmd_pmc_record.cc
290	Fixed!
503	Nevermind, I guess I missed someone updating those table. I switched for now to just unhalted-cycles. We need to cleanup the consistency across architectures still but it is currently defined on x86 and ARMv8+. I'll make a patch for power8/9 to define defaults.