PMDAPERFEVENT(1)

πŸ“¦
version 7.2.2 Β· 3 versions
, in arch rolling, centos-stream 10, centos-stream 9, debian trixie, fedora 43, fedora 44, ubuntu questing, ubuntu resolute, ubuntu stonking

πŸ’– PMDAPERFEVENT(1) πŸ’–

okay bestie, gather round, because today we're talking about pmdaperfevent β€” a Performance Metrics Domain Agent (PMDA for short, say it with me) from the Performance Co-Pilot manual pages, section 1, general commands. she's a little niche, she's a little powerful, and she is literally here to read your hardware performance counters. no cap. πŸ”₯


✨ NAME ✨

pmdaperfevent β€” hardware performance counter performance metrics domain agent (PMDA). yes that's a mouthful, no we're not changing it, it's iconic. πŸ‘‘


πŸ¦‹ SYNOPSIS πŸ¦‹

$PCP_PMDAS_DIR/perfevent/pmdaperfevent [-d domain] [-l logfile] [-U username] [-i port] [-p] [-u socket] [-6]

🌸 DESCRIPTION 🌸

okay so pmdaperfevent is a Performance Metrics Domain Agent (PMDA) that configures and reads the hardware performance counters using the Linux kernel perf_event API. that's the whole job. that's the vibe. πŸ’…

the perfevent PMDA exports metrics for hardware performance counters that are configurable from the Linux kernel perf_event API. it uses the libpfm4 library to get at those hardware performance counters, so basically any counter that libpfm4 supports should be available to you. slay.

also included (bonus content, we love her): the ability to read the Intel RAPL counters via direct MSR access. ✨

the PMDA supports automatically loading different counters for each hardware architecture. a single configuration file is used to specify the desired counters for each hardware performance monitoring unit (PMU). that config file lets you program different counters on different CPUs, and it supports round-robin assignment of uncore counters β€” which, fun fact, some AMD chips need. 🧚

the PMDA also counts events exposed in the kernel via the /sys/bus/event_source/devices directory. heads up though: the PMU device name and the event name must both be mentioned in the configuration file. otherwise the metric just won't be available to monitor through this PMDA. no config, no metric, that's the rule fr fr.

here's the tea though πŸ«– β€” the PMDA configures the counters to count events in <b>both user and kernel mode</b>. what does that mean for you? it means when the PMDA is using those hardware counters, normal unprivileged user applications can't use them. but don't panic, she's not mean! the PMDA provides a mechanism to temporarily disable the system-wide counters so regular users can grab the counters if they want. see perfalloc(1) for the deets. 😌

not me reminding you that pmdaperfevent is affected by the value of the kernel.perf_event_paranoid setting β€” which you can adjust with sysctl(8). just so you know. πŸ’€

a brief description of the pmdaperfevent command line options follows (and yes, we're doing all of them, every single one, because we don't skip):

  • -d β€” the performance metrics domain number. and bestie, it is absolutely crucial that this number is unique and consistent. meaning: domain should be different for every PMDA on the one host, and the same domain number should be used for the same PMDA on all hosts. do not freestyle this. 🚨
  • -l β€” location of the log file. by default, a log file named perfevent.log gets written in the current directory of pmcd(1) when pmdaperfevent is started, i.e. $PCP_LOG_DIR/pmcd. if the log file can't be created or isn't writable, output goes to standard error instead. she'll find a way to talk to you. πŸ’¬
  • -U β€” user account under which to run the agent. the default is the privileged "root" account. yes, root. she's powerful like that. πŸ‘‘
  • -i β€” listen on given port number for connection from pmcd(1)
  • -p β€” communicate with pmcd(1) via stdin/stdout
  • -u β€” expect pmcd(1) to connect on given unix domain socket
  • -6 β€” expect pmcd(1) to connect on given ipv6 port (number or name)

πŸŽ€ INSTALLATION πŸŽ€

plot twist: the perfevent PMDA is <b>not activated by default</b>. (i know. tragic.) to install the PMDA, do the following as root:

# cd $PCP_PMDAS_DIR/perfevent
# ./Install

and if you want to undo the installation (we've all been there), do the following as root:

# cd $PCP_PMDAS_DIR/perfevent
# ./Remove

pmdaperfevent is launched by pmcd(1) and should never be executed directly. like, ever. the Install and Remove scripts notify pmcd(1) when the agent is installed or removed, so they've got the whole thing handled. let them cook. πŸ“


🌈 FILES 🌈

  • $PCP_PMCDCONF_PATH β€” command line options used to launch pmdaperfevent
  • $PCP_PMDAS_DIR/perfevent/perfevent.conf β€” default configuration file for the PMDA. see perfevent.conf(5) for detailed information.
  • $PCP_PMDAS_DIR/perfevent/help β€” default help text file for the perfevent metrics
  • $PCP_PMDAS_DIR/perfevent/Install β€” installation script for the pmdaperfevent agent
  • $PCP_PMDAS_DIR/perfevent/Remove β€” undo installation script for the pmdaperfevent agent
  • $PCP_LOG_DIR/pmcd/perfevent.log β€” default log file for error messages and other information from pmdaperfevent

⭐ UPGRADING ⭐

okay so some metric names <b>changed starting in version 3.10.8</b> to better conform to PMNS conventions. (glow up era ✨) you can use pmlogrewrite(1) to update old archives. and there's a helper utility β€” $PCP_PMDAS_DIR/perfevent/perfevent-makerewrite.pl β€” that will generate a config file suitable for use with pmlogrewrite(1) to update the metric names in existing archives. she's got your back on the migration. 🫢


πŸ’€ BUGS πŸ’€

okay, the one thing we gotta be honest about: each event is placed in its own group, and there is no way to group related events together so they're guaranteed to be simultaneously active. 😭

a workaround for this is to ensure that the number of configured events is less than or equal to the number of available hardware counters. that way the events won't be time-multiplexed by the kernel and will be simultaneously active. iykyk. πŸ’…


πŸ’œ PCP ENVIRONMENT πŸ’œ

environment variables with the prefix PCP_ are used to parameterize the file and directory names used by PCP. on each installation, the file /etc/pcp.conf contains the local values for these variables. and the $PCP_CONF variable may be used to specify an alternative configuration file, as described in pcp.conf(5). 🌸


πŸ”₯ SEE ALSO πŸ”₯

perfalloc(1), perfevent.conf(5), PCPIntro(1), pmcd(1), pmlogrewrite(1), PMAPI(3), pcp.conf(5), pcp.env(5) and sysctl(8).


and that's the whole page, bestie! πŸ’– this one's brought to you by Performance Co-Pilot (PCP, the source, the moment, the icon) β€” go read the rest of her pages, she ate. mwah. πŸŽ€βœ¨πŸ¦‹

πŸ“¦ where this page comes from