This replaces a set but unused noop variable with a more explicit
macro.
Reviewed by: jkoshy, mhorne
Differential Revision: https://reviews.freebsd.org/D40651
- Make it clear that applications are not only encouraged to use the
pmc(3) library, but use of the hwpmc(4) interface directly is a
use-case we do not support
- Move the COMPATIBILITY section above PROGRAMMING API in hwpmc(4)
- Drop statements about the driver and library being "under development"
Reviewed by: jkoshy, emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40543
On an arm64 system that reports as a Cortex A72 r0p3, running
pmcstat -P CPU_CYCLES command
works, but
pmcstat -P cpu-cycles command
does not. This is because the former uses the PMU event from the JSON
source, resulting in pl_event in the log event being a small index
(here, 5) into the generated events table, whilst the latter does not
match any of the JSON events and falls back on PMC's own tables, mapping
it to the PMC event 0x14111, i.e. PMC_EV_ARMV8_EVENT_11H. Then, when
libpmc gets the PMCALLOCATE event, it tries to use the event as an index
into the JSON-derived table, but doing so only makes sense for the
former, whilst for the latter it will go way out of bounds and either
read junk (which may trigger the != NULL assertion) or segfault. As far
as I can tell we don't have anything lying around to tell us which of
the two cases we're in, but we can exploit the fact that the first
0x1000 PMC event codes are reserved, and that none of our PMU events
tables reach that number of entries yet.
PR: 268857
Reviewed by: mhorne
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D39592
When performing the syscall, specify the full name of the desired
operation. This improves grep-ability.
No functional change.
Reviewed by: jkoshy
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40334
Currently the PROCEXEC event only reports a single address, entryaddr,
which is the entry point of the interpreter in the typical dynamic case,
and used solely to calculate the base address of the interpreter. For
PDEs this is fine, since the base address is known from the program
headers, but for PIEs the base address varies at run time based on where
the kernel chooses to load it, and so pmcstat has no way of knowing the
real address ranges for the executable. This was less of an issue in the
past since PIEs were rare, but now they're on by default on 64-bit
architectures it's more of a problem.
To solve this, pass through what was picked for et_dyn_addr by the
kernel, and use that as the offset for the executable's start address
just as is done for everything in the kernel. Since we're changing this
interface, sanitise the way we determine the interpreter's base address
by passing it through directly rather than indirectly via the entry
point and having to subtract off whatever the ELF header's e_entry is
(and anything that wants the entry point in future can still add that
back on as needed; this merely changes the interface to directly provide
the underlying variables involved).
This will be followed up by a bump to the pmc major version.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D39595
Whilst the former is not breaking, the latter is, and so this will be
followed by a bump to the pmc major version. This will allow the flags
to actually be usable in future, as otherwise we cannot distinguish
uninitialised stack junk from a deliberately-initialised value.
Reviewed by: jhb, mhorne
Differential Revision: https://reviews.freebsd.org/D40049
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
This uses the C++ compiler as the linker instead of the C compiler
letting the compiler driver pick the right libraries. This is a no-op
on main and stable/13 but matters for stable/12 where the current
logic breaks for external GCC since it tries to use a non-existent
libstdc++.
Reviewed by: emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D39197
libpmc used -Wno-deprecated-declarations to silence warnings about usage
of deprecated std::auto_ptr, but there is (now) now use of auto_ptr in
libpmc.
Reviewed by: mhorne
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37576
Use calloc().
Walk the class list we get from kernel, so we will not add something
the kernel does not know about.
Avoid picking headers from /usr/include.
Differential Revision: https://reviews.freebsd.org/D36401
These are all "standard microarchitectural events", which in theory are
supported by every ARMv8 processor. In practice, it depends on the
pmu-event definitions being complete and accurate, which they are not
for every processor. Still, these aliases should be functional on the
majority of systems.
PR: 254532
Reported by: emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35550
Thanks to the recently updated import of the jevents utility by mav@, we
can now compile the latest version of these event definitions. This
should support a wider set of common ARMv8 processors, for example, the
Cortex-A72 in the Raspberry Pi 4.
This brings this folder in sync with Linux commit 62e6eb8d5454.
Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35549
Add support for system wide and NUMA domain wide counters support.
Add 3 new PMC classes for ARM DMC-620 and CMN-600 controllers PMU.
Reviewed by: mhorne
Sponsored By: ARM
Sponsored By: Ampere Computing
Differential Revision: https://reviews.freebsd.org/D35342
It is recommended by Intel to use fixed counters when possible to
leave programmable ones for different events.
This fixes `pmc stat`, which tries to count 6 events same time, while
many Intel CPUs have only 4 programmable counters.
MFC after: 1 month
Intel json's now have pretty reasonable fixed counters representation
via event=0 and umask. Hardcoded values create more confusion than fix.
MFC after: 1 month
Support the "usr" and "os" qualifiers on arm64 events to restrict
event counting to either usermode or the kernel, respectively. If
neither qualifier is given, events are counted in both.
Reviewed by: emaste
Sponsored by: University of Cambridge, Google, Inc.
Differential Revision: https://reviews.freebsd.org/D34527
This is useful for processors where we don't have an event table; in
those cases we default to a Cortex A8 (armv7) or Cortex A53 (arm64) in
order to attempt to provide something useful, but you're then limited to
the counters in those tables, some of which may also not be implemented
(e.g. LD/ST_RETIRED are no longer implemented in more recent cores,
replaced by LD/ST_SPEC).
Adding the raw EVENT_xxH event lists to each table ensures that you can
always request the exact events you want, regardless of what has been
detected or is known.
Reviewed by: mhorne
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D33805
Make it mostly compatible with what's defined for Intel. Except where
noted, these are defined for all of amdzen(1|2|3).
Reviewed by: emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32162
Looking for "tsc-tsc" in the pmu tables will fail every time. Instead,
make this an alias for the static TSC event defined in pmc_events.h.
This fixes 'pmcstat -s cycles' on Intel and AMD.
Reviewed by: emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32197
Support for Pentium events was removed completely in e92a1350b5.
Don't bump .Dd where we are just removing xrefs.
Reviewed by: emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31423
After b48a2770d4, static POWER8 definitions became unnecessary,
as all of them (and much more) are already present in libpmc's
PMU events.
Submitted by: Leonardo Bianconi <leonardo.bianconi@eldorado.org.br> (initial version)
Reviewed by: kbowling, mhorne
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D31334
Due to a mis-merge, the changes committed to libpmc never called
pmu_parse_event(), or set pm->pm_ev. However, this field shouldn't be
used to carry the actual pmc event code anyway, as it is expected to
contain the index into the pmu event array (otherwise, it breaks event
name lookup in pmclog_get_event()). Add a new MD field,
pm_md.pm_md_config, to pass the raw event code to arm64_allocate_pmc().
Additionally, the change made to pmc_md_op_pmcallocate was incorrect, as
this is a union, not a struct. Restore the proper padding size.
Reviewed by: luporl, ray, andrew
Fixes: 28dd6730a5 ("libpmc: enable pmu_utils on arm64")
Fixes: 8cc3815f02 ("hwpmc_arm64: accept raw event codes...")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31221
- new sentence, new line
- tab in filled text
- unusual Xr order
- skipping paragraph macro: Pp before Ss
Reviewed by: bcr
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31143
This allows supported libpmc to query/select from the pmu-events table,
which may have a more complete set of events than what we define
manually. A future update to these definitions should greatly improve
this support. The alias table is empty for now, until this future import
is complete.
Add the Foundation's copyright for recent work on this file.
Reviewed by: ray (slightly earlier version)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D30603
The current version has every function stubbed out for !x86. Only two
functions (pmu_alias_get() and pmc_pmu_pmcallocate() are really platform
dependent, so reduce the width of the ifdefs and remove some of the
stubs.
Reviewed by: ray
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D30532
Although currently unused, there are only pmu event definitions for
POWER8 and POWER9. There is no sense in building these on 32-bit
platforms.
Sponsored by: The FreeBSD Foundation