Page MenuHomeFreeBSD

sys: hwpmc PMU group/multiplex ABI additions
Needs ReviewPublic

Authored by afscoelho_gmail.com on Jun 18 2026, 7:05 AM.
Tags
None
Referenced Files
F176609814: D57630.id190295.diff
Tue, Oct 20, 5:25 AM
F176604602: D57630.id190295.diff
Tue, Oct 20, 4:18 AM
F176602876: D57630.id189811.diff
Tue, Oct 20, 3:58 AM
F176600266: D57630.id185744.diff
Tue, Oct 20, 3:26 AM
Unknown Object (File)
Mon, Oct 19, 4:15 PM
Unknown Object (File)
Mon, Oct 19, 1:49 PM
Unknown Object (File)
Mon, Oct 19, 11:40 AM
Unknown Object (File)
Mon, Oct 19, 9:09 AM
Subscribers
None

Details

Summary

Add the user and kernel ABI for PMC event groups. A group is a set of
PMCs that the hardware must count together. Each member counts over the
same interval.

User ABI:

  • PMCGROUPCREATE, PMCGROUPADD, and PMCGROUPCOMMIT create a group and freeze its configuration.
  • PMCGROUPREAD returns member counts and group time data in one call. Userland scales counts from this data.
  • PMC_F_GROUP_MUX allows multiplexing when a group does not fit the available hardware counters.
  • PMC_F_GROUP_DEFER delays hardware row assignment until group commit.
  • Each group supports up to PMC_GROUP_MAX_MEMBERS members.

Bump PMC_VERSION_MINOR to 0x04 for the new operations and flags.

Kernel ABI:

  • struct pmc_process gains lists for group anchors, group-target links, and per-thread sampling residuals. A lock protects these lists.
  • struct pmc_owner gains a group list and deferred handle pools.
  • A deferred handle gives each member a stable user-visible ID before hardware row assignment.
  • PMC_HANDLE_DEFERRED_* encodes a slot index and a generation counter. The generation counter separates consecutive uses of a slot.
  • struct pmc_classdep gains optional pcd_can_assign_pmc and pcd_get_sched_constraint callbacks. These let each class describe its row constraints.

Co-authored-by: Raghavendra K T <raghavendra.kt@amd.com>
Sponsored by: AMD

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 78371
Build 75254: arc lint + arc unit

Event Timeline

imp added inline comments.
sys/sys/pmc.h
394–396

So is this new Vxx API then?

This revision is now accepted and ready to land.Jun 24 2026, 11:42 PM
sys/sys/pmc.h
394–396

So is this new Vxx API then?

Thank you for the review. Yes.

@raghavendra.kt_amd.com

I'm assuming we are going to multiplex the counters based on the sample 'rate'?

@raghavendra.kt_amd.com

I'm assuming we are going to multiplex the counters based on the sample 'rate'?

Thank you for your reviews and support Ali. Sorry for late reply. It took long time before I could get system wide core counting work.

To answer the question: In this patch series, private core counters' grouping and multiplexing works. Sampling event support is yet to be added.

I do have a systemwide event counting working at "https://github.com/AMDESE/freebsd-src/tree/amdese/feature/pmc/grouping_mux_upstream_v0".

I will clean it up and submit along with your review comments added in other patches and resubmit. ( I hope git-arc supports top up patch)

afscoelho_gmail.com updated this revision to Diff 185744.

Update to the rebuilt PerfMonV2 grouping and multiplexing stack.

This revision now requires review to proceed.Sep 8 2026, 12:33 PM

Rebase onto main after D58256 landed. Bump PMC_VERSION_MINOR to 0x04, since main is now at 0x03.

Rebase on main (D60141 and D60185 are committed). No change.

PMCGROUPRELEASE is mentioned in the commit message but not in this diff. Please update the message.

Also in general instead of calling these things 'pmu' we should rename it into group or multiplex or something more clear. Particularly the file name for 631 should be pmc_grouping since most functions are prefixed as such.

sys/sys/pmc.h
366

Move the comment up here and leave the define probably. Also don't need to tell us 40 is free.

403

Why is this marked obsolete. reserved.? should you remove this? It's mentioned in your commit message you might need to update that.

901

I don't see logic that prevents PMC_HANDLE_DEFERRED_ROW(31,3) from equalling PMC_ROW_UNASSIGNED? Isn't that a problem?

I would rather also we have more bits to spare so we can reuse grouping eventually for handling multiple processes.

This revision now requires changes to proceed.Thu, Oct 15, 8:47 AM

Address review: keep PMC_F_UNUSED1 and move its comment, remove PMC_F_SCALED, document why a deferred handle never equals PMC_ROW_UNASSIGNED.

Thanks for the review!
The summary still lists PMCGROUPRELEASE and PMC_F_SCALED from an older version. I will update it to match the current code. I will rename hwpmc_pmu.c to hwpmc_grouping.c and change the related names in a separate rename-only revision so it keeps the current review diffs stable. I will do this before the stack lands.

sys/sys/pmc.h
403

PMC_F_SCALED comes from an older version of this series, good catch!
Removing it.

901

We cannot use PMC_ROW_UNASSIGNED for all deferred members. Each member needs its own ID before commit, If we use it for every handle, members with the same CPU, mode, and class get the same ID. Each member needs its own ID so a read or release reaches the correct PMC.
About the bits, the handle uses the row field that has 8 bits. The other fields store the CPU, mode, and class. I think more bits would need a different ID layout or a separate handle.

Would you be OK with a separate rename-only revision for the pmu names at the end of the stack?