Re: Heads up: official removal of older AMD (pre-Zen1) support from libpmc/hwpmc

Hi Adrian,

On 4/21/26 13:23, Adrian Chadd wrote:
> On Tue, 21 Apr 2026 at 08:41, Mitchell Horne <[email protected]> wrote:
>>
>> Hello,
>>
>> As the title suggests, I have proposed a change [1] to officially remove
>> the older AMD processor event definitions and logic from the library and
>> module. This means that processors older than the Zen 1 generation
>> (~2017) will not be supported by these tools.
>>
>> I say "officially" because the functionality has been silently disabled
>> for these older processors since 2020 at least [2].
>>
>> Among the many known issues, bugs, and sharp-edges relating to hwpmc(4)
>> and its tools, I am not aware of this complaint being raised or reported
>> anywhere. (Not to say that users haven't experienced this frustrating
>> silent failure.)
>>
> 
> I mostly object, mostly because I'd rather we figure out why we've regressed in
> this area and try to fix it to stop it happening in the future.
> 

The exact technical reason for this case is largely uninteresting. It
stems from major work that took place to migrate to the new event
sources, which we receive from upstream linux. And a later change did
not adequately test on the older hardware.

My input on how to understand the regressions generally is below.

> I have a variety of AMD hardware sprinkled around at home going back to K7
> era stuff that we still boot/run on (and heck I remember debugging our
> earlier AMD counter programming bugs way back when.)
> 
> Please don't take "noone has complained" as "noone is using this so we can
> delete it" - I would take it as "everything is utterly broken in stupid ways and
> we should fix the utterly broken stuff and figure out how to make sure it
> isn't broken over time in the future."
> 

I agree that "noone has complained" does not give a complete picture.
What I am reporting is that "nobody can be using this"; it is broken on
every active release, even stable/12.

> hwpmc being broken in 1000 subtle stupid ways has been a thorn in my butt
> since I jumped back into FreeBSD a couple years ago and I would love to
> collaborate on fixing said broken stuff in a way that makes it not break
> in the future.
> 

I too have put in my time with the PMC stack over the past 5 years or
so, doing some difficult digging into the obscure issues and providing a
large portion of the maintenance. It is an endless quagmire. But my
efforts have given some perspective...

The main reason for the obscure breakages in the PMC stack is due to its
absolutely massive surface area across kernel, library, utilities, docs.
It is impossible for any individual to test it adequately, due to its
(necessary) complexity, fragility, and support for hundreds of CPU
models and thousands of event definitions.

The situation is thus: There are few maintainers, or people with the
bandwidth to work on bugs or QA here. It is only new CPU support that
gets regular attention. There are few people with a big-picture
understanding of the codebase who can provide review or guidance on its
evolution, so some new features have been applied with duct tape, so to
speak.

In this situation there is no avoiding regressions. It is a fantasy.

What can be done now is provide clear(er) boundaries on what is
supported w.r.t. hardware, API, ABI; and shrink the surface area
wherever possible. Otherwise, an effort to collect the known issues and
prioritize them would be very fruitful (more below).

Personally I am working (very slowly) on these things. There is some
recent interest and contributions to the AMD code, so that is part of
where this is coming from.

Returning to proposed change: Here, the decision to deprecate was
effectively made for us, and the support window has lapsed. To re-enable
it now would be a move against our best best interests w.r.t.
maintenance and testing.

> (And for me that starts with "pmcannotate is broken", and "the pmc tools have
> no idea how to find kernel stuff in /usr/lib/debug as it was never
> migrated to it
> in the first place", and both of those are huge "out of box" issues for me.)
> 
> (And then it gets down to "which counters do I use" and "why aren't defaults
> consistently implemented between cpu family/arch/microarch" but that's
> the next discussion after I can /run/ it on a out of box install..)
> 

I really think this is what you should target then! No doubt there are
others experiencing the same.

My hope/intention for the next few months is to start putting together a
plan/roadmap for this stuff. There are many gripes that we have with
these tools as individuals. Taking inventory from existing bugs, users,
and developers may inform our collective priorities here.

Right now my limited time is being allocated towards reviewing the new
code that is coming in.

Mitchell

> 
> 
> -adrian
>