Page MenuHomeFreeBSD

sys: hwpmc PMU group/multiplex ABI additions
Needs RevisionPublic

Authored by afscoelho_gmail.com on Jun 18 2026, 7:05 AM.
Tags
None
Referenced Files
F176073030: D57630.id185744.diff
Thu, Oct 15, 8:57 PM
F175992113: D57630.id189811.diff
Thu, Oct 15, 2:45 AM
Unknown Object (File)
Wed, Oct 14, 10:44 PM
Unknown Object (File)
Wed, Oct 14, 3:03 AM
Unknown Object (File)
Thu, Oct 8, 10:17 PM
Unknown Object (File)
Wed, Oct 7, 1:29 AM
Unknown Object (File)
Tue, Oct 6, 11:28 PM
Unknown Object (File)
Mon, Oct 5, 6:48 PM
Subscribers
None

Details

Summary

Add the userland-visible additions that the hwpmc PMU group/multiplex
work needs:

  • PMC_OP_PMCGROUPCREATE / PMCGROUPADD / PMCGROUPCOMMIT / PMCGROUPRELEASE are appended to enum pmc_ops.
  • PMC_F_GROUP_DEFER, PMC_F_GROUP_MUX, PMC_F_SCALED extend the pmc_op_pmcallocate / pmc_op_pmcrw flag space. PMC_F_GROUP_DEFER is placed at 0x40 because bit 0 (PMC_PP_ENABLE_MSR_ACCESS) is compared against pm->pm_flags by the existing attach path and would otherwise produce spurious EPERM.
  • pmc_op_pmcgroup{create,add,commit,release} and a stable per-owner PMC_HANDLE_DEFERRED_{BASE,MAX} range used by the kernel to give each deferred-group PMC a user-facing id (struct pmc::pm_handle) that survives the assigner rewriting pm_id with a real hardware row.
  • pm_runtime / pm_enabledtime fields are added to pmc_op_pmcrw for scaled reads.
  • struct pmc_process gains pp_pmu_groups (every committed group currently bound to the process), pp_pmu_rot_thread (the per-pp rotation kthread), pp_pmu_rot_cursor (round-robin start position for the next rotation tick), and pp_pmu_rot_* time-slice fields used by the rotation runtime added in patch 0002.

The two PMU-layer aggregates referenced from struct pmc and
struct pmc_process are forward-declared here as the opaque typedefs
pmu_event_t and pmu_group_t (full definitions live in
sys/dev/hwpmc/hwpmc_pmu.h, patch 0002); struct pmc::pm_pmu and
struct pmc_process::pp_pmu_rot_cursor use those typedef spellings.
The forward declarations sit under #ifdef _KERNEL so the userland ABI
is untouched.

PMC_VERSION_API_MINOR is bumped. Strictly additive: existing user
binaries continue to work.
Sponsored by: AMD
Signed-off-by: Raghavendra K T <raghavendra.kt@amd.com>

Diff Detail

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

Event Timeline

imp added inline comments.
sys/sys/pmc.h
393

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
393

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.

400

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

905

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