Page MenuHomeFreeBSD

fix pmcstat

Authored by gallatin on Jul 4 2022, 3:48 PM.



pmcstat has been broken for analyzing logs since D35342 / b6e28991bf3aadb.

This is because the pmc for the first CPU is not added when reading logs because unlike its clones, its event id is not invalid. That causes us to fail the assertion at lib/libpmcstat/libpmcstat_logging.c:293 when encountering samples from cpu0.

Diff Detail

rG FreeBSD src repository
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

gallatin added a reviewer: tsoome.

Seems to be good. and on this arm64 machine, it does work:

[1] + Done /usr/obj/usr/home/toomas.soome/src/arm64.aarch64/usr.sbin/pmcstat/pmcstat -n 1000000 -S CPU_CYCLES -O out.pmclog_cpi01 sleep 15
root@snow3:~toomas.soome/src/usr.sbin/pmcstat #
root@snow3:~toomas.soome/src/usr.sbin/pmcstat # /usr/obj/usr/home/toomas.soome/src/arm64.aarch64/usr.sbin/pmcstat/pmcstat -R out.pmclog_cpi01 -z 32 -G out.pmcstat_cpi01
#exec/elf 6
#samples/total 28
root@snow3:~toomas.soome/src/usr.sbin/pmcstat #

This revision is now accepted and ready to land.Jul 4 2022, 4:08 PM
This revision was automatically updated to reflect the committed changes.
mhorne added inline comments.

Does pmc_allocate() with an event ID of PMC_ID_INVALID return zero?


I don't see the err() text printed, so it must.

I don't pretend to know how this works, I debugged this by realizing that the samples that were causing pmcstat to crash were coming from CPU 0, and that CPU 0 was apparently not added someplace. I deduced that CPUs 1..N were cloned from CPU 0 and had PMC_ID_INVALID immediately after being cloned. Removing this check got CPU 0 added wherever it needed to be added to keep pmcstat from crashing due to being unable to lookup the samples when analyzing logs. I'm happy if there is a better fix, but what we have now unbreaks a perf analysis workflow that has worked for years.