PEPC-PMQOS(1)

📦 version 2.0.7, in epel 10, epel 9, fedora 44

✨ Command pmqos ✨

okay so bestie, meet pmqos 💅 — the PM QoS (Power Management Quality of Service) command. Here's everything it can do, no skips, no cap.

🎀 General options 🎀

  • -h — show a short help message and dip out. bye 👋
  • -q — be quiet. Only the important stuff gets printed, like warnings.
  • -d — print debugging information.
  • --debug-modules MODNAME[,MODNAME1,...] — okay so -d turns on every single debug message, which is a lot. This option narrows them down to just the modules you name. For example, -d --debug-modules MSR will only show debug messages coming from the MSR module. obsessed with the precision ✨
  • --version — print the version number and exit.
  • -H HOSTNAME, --host HOSTNAME — the host name or IP address of the target system. The pepc command will be executed on that system using SSH instead of running locally. If you don't specify it, the command runs locally. 🏠
  • -U USERNAME, --username USERNAME — the name of the user to use for logging into the remote host over SSH. By default it looks up the user name in SSH configuration files, and if it's not found there, it uses the current user name.
  • -K PRIVKEY, --priv-key PRIVKEY — path to the private SSH key for logging into the remote host. If you don't specify one, the keys configured for the host in SSH configuration files (e.g. ~/.ssh/config) get used. If no keys are configured there, standard key files (e.g. ~/.ssh/id_rsa) and the SSH agent are tried. 🔑
  • -D DATASET, --dataset DATASET — this one is for debugging and testing, bestie. It specifies the dataset to use for emulating the host you're running the command on. The datasets live in the pepc source code repository.

The argument can be a dataset path or a dataset name. If you specify it by name, these locations get searched for the dataset:

  1. ./tests/emul-data in the program's directory
  2. $PEPC_DATA_PATH/tests/emul-data
  3. $VIRTUAL_ENV/share/pepc/tests/emul-data
  4. $HOME/.local/share/pepc/tests/emul-data
  5. /usr/local/share/pepc/tests/emul-data
  6. /usr/share/pepc/tests/emul-data
  • --force-color — force colorized output even if the output stream is not a terminal (it adds ANSI escape codes). slay 🌈
  • --print-man-path — print the pepc manual pages directory path and exit. Add this path to the MANPATH environment variable to make the manual pages available to the man tool. 📖

🌸 Target CPU specification options 🌸

All subcommands (info, config) accept the following target CPU specification options. 🎯

  • --cpus CPUS — the list can include individual CPU numbers and CPU number ranges. For example, 1-4,7,8,10-12 would mean CPUs 1 to 4, CPUs 7, 8, and 10 to 12. Use the special keyword all to specify all CPUs.
  • --cores CORES — the list can include individual core numbers and core number ranges. For example, 1-4,7,8,10-12 would mean cores 1 to 4, cores 7, 8, and 10 to 12. Use the special keyword all to specify all cores. Core numbers are relative to the package.
  • --modules MODULES — the list can include individual module numbers and module number ranges. For example, 0,2-5 would mean module 0 and modules 2, 3, 4, and 5. Use the special keyword all to specify all modules. Note that unlike core and die numbers, module numbers are absolute. 👑
  • --dies DIES — the list can include individual die numbers and die number ranges. For example, 0-3,5 would mean dies 0 to 3, and die 5. Use the special keyword all to specify all dies. On some systems, die numbers are globally unique, while on other systems they are relative to the package. it's giving "depends on the system" energy 😌
  • --packages PACKAGES — the list can include individual package numbers and package number ranges. For example, 0,2-4 would mean package 0 and packages 2 to 4. Use the special keyword all to specify all packages.
  • --core-siblings CORE_SIBLINGS — core siblings are CPUs sharing the same core. The list can include individual core sibling indices or index ranges. For example, if a core includes CPUs 3 and 4, index 0 would mean CPU 3 and index 1 would mean CPU 4. This option can only be used to reference online CPUs, because Linux does not provide topology information for offline CPUs. In the example with CPUs 3 and 4, if CPU 3 was offline, then index 0 would mean CPU 4 and index 1 would be invalid. 💀
  • --module-siblings MODULE_SIBLINGS — module siblings are CPUs sharing the same module. The list can include individual module sibling indices or index ranges. For example, if a module includes CPUs 3, 4, 5, and 6, index 0 would mean CPU 3, index 1 would mean CPU 4, index 2 would mean CPU 5, and index 3 would mean CPU 6. This option can only be used to reference online CPUs, because Linux does not provide topology information for offline CPUs. In the example with CPUs 3, 4, 5, and 6, if CPU 4 was offline, then index 1 would mean CPU 5, index 2 would mean CPU 6, and index 3 would be invalid. same energy, different sibling 🧚

🦋 Subcommand info 🦋

Retrieve PM QoS (Power Management Quality of Service) information for specified CPUs. By default, display all details for all CPUs. Use the target CPU specification options to define a subset of CPUs, cores, dies, or packages. 🔍

  • -m MECHANISMS, --mechanisms MECHANISMS — a comma-separated list of mechanisms for retrieving information. Use --list-mechanisms to view the available mechanisms. Many options support only one mechanism (e.g., sysfs), while others may support multiple. Mechanisms are tried in the specified order. By default, all mechanisms are allowed, and the most preferred ones are tried first.
  • --list-mechanisms — display the available mechanisms for retrieving PM QoS information.
  • --latency-limit — retrieve the per-CPU Linux PM QoS limit. This limit affects C-state selection by restricting the kernel from using C-states with latencies exceeding the specified limit. For example, a 50us limit ensures the kernel only selects C-states with latencies ≤ 50us. The limit is read from /sys/devices/system/cpu/cpu<N>/power/pm_qos_resume_latency_us. 😴💤
  • --global-latency-limit — retrieve the global Linux PM QoS limit. This limit, unlike the per-CPU latency limit, applies globally. It is read from the /dev/cpu_dma_latency device node. 🌍
  • --yaml — display information in YAML format. 📝

🍓 Subcommand config 🍓

Configure PM QoS (Power Management Quality of Service) for specified CPUs. If no parameter is provided, the current value(s) will be displayed. Use the target CPU specification options to define the subset of CPUs, cores, dies, or packages. 🛠️

  • -m MECHANISMS, --mechanisms MECHANISMS — a comma-separated list of mechanisms allowed for configuring PM QoS. Use --list-mechanisms to view the available mechanisms. Mechanisms are tried in the specified order. By default, all mechanisms are allowed, and the most preferred ones are tried first.
  • --list-mechanisms — display the available mechanisms for configuring PM QoS.
  • --latency-limit [LATENCY_LIMIT] — set the per-CPU Linux PM QoS limit, which restricts the kernel from using C-states with latencies exceeding the specified value. For example, a 50us limit ensures the kernel selects only C-states with latencies ≤ 50us. The limit is configured via /sys/devices/system/cpu/cpu<N>/power/pm_qos_resume_latency_us. The default unit is us (microseconds), but ns, ms, and s units are also supported (e.g., 1ms). Value 0 disables the limit.
Note: Setting the global latency limit is unsupported. The /dev/cpu_dma_latency API requires the caller to keep the device open for the limit to remain in effect. The limit is removed as soon as the device is closed. so like... it evaporates the second you look away 🙈

and that's the whole page, bestie 💖 this was PEPC-PMQOS(1) from the General Commands Manual — that's the footer energy right there, and it's the whole vibe. go forth and QoS, you absolute icon 👑✨

📦 where this page comes from