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

Hello Everyone,

I'd like to put forward an alternative proposal which is to convert the K8
counters into JSON definitions just like any other processor.  This
approach allows all the custom K8 code in libpmc and in the kernel module
to be replaced by a couple of lines in the existing libpmc JSON path.

All counters will continue to work, but we will change the way masks fork
for about a dozen counters.

Old syntax: pmcstat -s k8_dc_refill_from_system,mask=shared

New syntax: pmcstat -s k8_dc_refill_from_system.shared
- or -
New syntax: pmcstat -s k8_dc_refill_from_system,mask=0x2

Like all other processors the (dot) syntax is hard coded in the JSON so
combinations like below would have only support manually computed masks.

Old syntax: pmcstat -s k8_dc_refill_from_system,mask=shared+exclusive

New syntax: pmcstat -s k8_dc_refill_from_system,mask=0x6

Best,
Ali

On Tue, Apr 21, 2026 at 2:24 PM Mitchell Horne <[email protected]> wrote:

>
>
> On 4/21/26 13:49, Lionel Cons wrote:
> > On Tue, 21 Apr 2026 at 18:24, Adrian Chadd <[email protected]> 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.
> >>
> >> 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 also object, mostly because I stumbled across the issue that my
> > organisation has several large clusters with older AMD CPUs with
> > FreeBSD in use [*]
> >
> > [*] How, why, who, still under investigation since we found out. It's
> > in legitimate use, running recent FreeBSD, and couple of department
> > heads wanted to hang me when we touched it. So yes, old stuff is being
> > used, and no money to replace it for now.
> >
> > Lionel
> >
>
> Cool, understood. I guess your insight is still incomplete into this,
> but can you expand briefly on the use-case of these machines?
>
> Is it likely that they require the use of hardware performance
> monitoring, i.e. pmcstat(8)? As I've noted, it would be non-functional
> in CURRENT without local modifications.
>
> Best,
> Mitchell
>
>