Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
/*
|
|
|
|
htop - linux/Platform.c
|
|
|
|
(C) 2014 Hisham H. Muhammad
|
2021-03-16 22:54:15 +00:00
|
|
|
(C) 2020-2021 htop dev team
|
PCP: support for 'dynamic columns' added at runtime
Implements support for arbitrary Performance Co-Pilot
metrics with per-process instance domains to form new
htop columns. The column-to-metric mappings are setup
using configuration files which will be documented via
man pages as part of a follow-up commit.
We provide an initial set of column configurations so
as to provide new capabilities to pcp-htop: including
configs for containers, open fd counts, scheduler run
queue time, tcp/udp bytes/calls sent/recv, delay acct,
virtual machine guests, detailed virtual memory, swap.
Note there is a change to the configuration file path
resolution algorithm introduced for 'dynamic meters'.
First, look in any custom PCP_HTOP_DIR location. Then
iterate, in priority order, users home directory, then
local sysadmins files in /etc/pcp/htop, then readonly
configuration files below /usr/share/pcp/htop. This
final location becomes the preferred place for our own
shipped meter and column files.
The Settings file (htoprc) writing code is updated to
not using the numeric identifier for dynamic columns.
The same strategy used for dynamic meters is used here
where we write Dynamic(name) so the name can be setup
once more at start. Regular (static) columns writing
to htoprc - i.e. numerically indexed - is unchanged.
2021-07-11 01:11:29 +00:00
|
|
|
(C) 2020-2021 Red Hat, Inc.
|
2021-09-22 09:33:00 +00:00
|
|
|
Released under the GNU GPLv2+, see the COPYING file
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
in the source distribution for its full text.
|
|
|
|
*/
|
|
|
|
|
2021-04-14 01:34:47 +00:00
|
|
|
#include "config.h" // IWYU pragma: keep
|
|
|
|
|
2021-06-07 03:46:29 +00:00
|
|
|
#include "pcp/Platform.h"
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
|
|
|
|
#include <math.h>
|
2021-08-14 21:30:19 +00:00
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <string.h>
|
|
|
|
#include <unistd.h>
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
|
|
|
|
#include "BatteryMeter.h"
|
|
|
|
#include "CPUMeter.h"
|
2021-08-14 21:30:19 +00:00
|
|
|
#include "ClockMeter.h"
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
#include "DateMeter.h"
|
|
|
|
#include "DateTimeMeter.h"
|
|
|
|
#include "DiskIOMeter.h"
|
2021-08-14 21:30:19 +00:00
|
|
|
#include "DynamicColumn.h"
|
2021-06-23 07:44:56 +00:00
|
|
|
#include "DynamicMeter.h"
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
#include "HostnameMeter.h"
|
|
|
|
#include "LoadAverageMeter.h"
|
|
|
|
#include "Macros.h"
|
|
|
|
#include "MemoryMeter.h"
|
2021-08-10 19:32:05 +00:00
|
|
|
#include "MemorySwapMeter.h"
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
#include "Meter.h"
|
|
|
|
#include "NetworkIOMeter.h"
|
|
|
|
#include "ProcessList.h"
|
|
|
|
#include "Settings.h"
|
|
|
|
#include "SwapMeter.h"
|
2021-03-05 05:35:32 +00:00
|
|
|
#include "SysArchMeter.h"
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
#include "TasksMeter.h"
|
|
|
|
#include "UptimeMeter.h"
|
|
|
|
#include "XUtils.h"
|
2021-04-14 01:34:47 +00:00
|
|
|
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
#include "linux/PressureStallMeter.h"
|
|
|
|
#include "linux/ZramMeter.h"
|
|
|
|
#include "linux/ZramStats.h"
|
PCP: support for 'dynamic columns' added at runtime
Implements support for arbitrary Performance Co-Pilot
metrics with per-process instance domains to form new
htop columns. The column-to-metric mappings are setup
using configuration files which will be documented via
man pages as part of a follow-up commit.
We provide an initial set of column configurations so
as to provide new capabilities to pcp-htop: including
configs for containers, open fd counts, scheduler run
queue time, tcp/udp bytes/calls sent/recv, delay acct,
virtual machine guests, detailed virtual memory, swap.
Note there is a change to the configuration file path
resolution algorithm introduced for 'dynamic meters'.
First, look in any custom PCP_HTOP_DIR location. Then
iterate, in priority order, users home directory, then
local sysadmins files in /etc/pcp/htop, then readonly
configuration files below /usr/share/pcp/htop. This
final location becomes the preferred place for our own
shipped meter and column files.
The Settings file (htoprc) writing code is updated to
not using the numeric identifier for dynamic columns.
The same strategy used for dynamic meters is used here
where we write Dynamic(name) so the name can be setup
once more at start. Regular (static) columns writing
to htoprc - i.e. numerically indexed - is unchanged.
2021-07-11 01:11:29 +00:00
|
|
|
#include "pcp/PCPDynamicColumn.h"
|
2021-06-23 07:44:56 +00:00
|
|
|
#include "pcp/PCPDynamicMeter.h"
|
2021-08-14 21:30:19 +00:00
|
|
|
#include "pcp/PCPMetric.h"
|
2021-06-07 03:46:29 +00:00
|
|
|
#include "pcp/PCPProcessList.h"
|
2021-02-22 05:45:44 +00:00
|
|
|
#include "zfs/ZfsArcMeter.h"
|
|
|
|
#include "zfs/ZfsArcStats.h"
|
|
|
|
#include "zfs/ZfsCompressedArcMeter.h"
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
|
2021-03-05 05:35:32 +00:00
|
|
|
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
Platform* pcp;
|
|
|
|
|
|
|
|
ProcessField Platform_defaultFields[] = { PID, USER, PRIORITY, NICE, M_VIRT, M_RESIDENT, (int)M_SHARE, STATE, PERCENT_CPU, PERCENT_MEM, TIME, COMM, 0 };
|
|
|
|
|
|
|
|
int Platform_numberOfFields = LAST_PROCESSFIELD;
|
|
|
|
|
|
|
|
const SignalItem Platform_signals[] = {
|
|
|
|
{ .name = " 0 Cancel", .number = 0 },
|
|
|
|
};
|
|
|
|
|
|
|
|
const unsigned int Platform_numberOfSignals = ARRAYSIZE(Platform_signals);
|
|
|
|
|
|
|
|
const MeterClass* const Platform_meterTypes[] = {
|
|
|
|
&CPUMeter_class,
|
2021-06-23 07:44:56 +00:00
|
|
|
&DynamicMeter_class,
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
&ClockMeter_class,
|
|
|
|
&DateMeter_class,
|
|
|
|
&DateTimeMeter_class,
|
|
|
|
&LoadAverageMeter_class,
|
|
|
|
&LoadMeter_class,
|
|
|
|
&MemoryMeter_class,
|
|
|
|
&SwapMeter_class,
|
2021-08-10 19:32:05 +00:00
|
|
|
&MemorySwapMeter_class,
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
&TasksMeter_class,
|
|
|
|
&UptimeMeter_class,
|
|
|
|
&BatteryMeter_class,
|
|
|
|
&HostnameMeter_class,
|
|
|
|
&AllCPUsMeter_class,
|
|
|
|
&AllCPUs2Meter_class,
|
|
|
|
&AllCPUs4Meter_class,
|
|
|
|
&AllCPUs8Meter_class,
|
|
|
|
&LeftCPUsMeter_class,
|
|
|
|
&RightCPUsMeter_class,
|
|
|
|
&LeftCPUs2Meter_class,
|
|
|
|
&RightCPUs2Meter_class,
|
|
|
|
&LeftCPUs4Meter_class,
|
|
|
|
&RightCPUs4Meter_class,
|
|
|
|
&LeftCPUs8Meter_class,
|
|
|
|
&RightCPUs8Meter_class,
|
|
|
|
&BlankMeter_class,
|
|
|
|
&PressureStallCPUSomeMeter_class,
|
|
|
|
&PressureStallIOSomeMeter_class,
|
|
|
|
&PressureStallIOFullMeter_class,
|
|
|
|
&PressureStallMemorySomeMeter_class,
|
|
|
|
&PressureStallMemoryFullMeter_class,
|
2021-02-22 05:45:44 +00:00
|
|
|
&ZfsArcMeter_class,
|
|
|
|
&ZfsCompressedArcMeter_class,
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
&ZramMeter_class,
|
|
|
|
&DiskIOMeter_class,
|
|
|
|
&NetworkIOMeter_class,
|
2021-03-05 05:35:32 +00:00
|
|
|
&SysArchMeter_class,
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
2021-07-09 02:42:36 +00:00
|
|
|
static const char* Platform_metricNames[] = {
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
[PCP_CONTROL_THREADS] = "proc.control.perclient.threads",
|
|
|
|
|
|
|
|
[PCP_HINV_NCPU] = "hinv.ncpu",
|
|
|
|
[PCP_HINV_CPUCLOCK] = "hinv.cpu.clock",
|
|
|
|
[PCP_UNAME_SYSNAME] = "kernel.uname.sysname",
|
|
|
|
[PCP_UNAME_RELEASE] = "kernel.uname.release",
|
|
|
|
[PCP_UNAME_MACHINE] = "kernel.uname.machine",
|
2021-03-05 05:35:32 +00:00
|
|
|
[PCP_UNAME_DISTRO] = "kernel.uname.distro",
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
[PCP_LOAD_AVERAGE] = "kernel.all.load",
|
|
|
|
[PCP_PID_MAX] = "kernel.all.pid_max",
|
|
|
|
[PCP_UPTIME] = "kernel.all.uptime",
|
|
|
|
[PCP_BOOTTIME] = "kernel.all.boottime",
|
|
|
|
[PCP_CPU_USER] = "kernel.all.cpu.user",
|
|
|
|
[PCP_CPU_NICE] = "kernel.all.cpu.nice",
|
|
|
|
[PCP_CPU_SYSTEM] = "kernel.all.cpu.sys",
|
|
|
|
[PCP_CPU_IDLE] = "kernel.all.cpu.idle",
|
|
|
|
[PCP_CPU_IOWAIT] = "kernel.all.cpu.wait.total",
|
|
|
|
[PCP_CPU_IRQ] = "kernel.all.cpu.intr",
|
|
|
|
[PCP_CPU_SOFTIRQ] = "kernel.all.cpu.irq.soft",
|
|
|
|
[PCP_CPU_STEAL] = "kernel.all.cpu.steal",
|
|
|
|
[PCP_CPU_GUEST] = "kernel.all.cpu.guest",
|
|
|
|
[PCP_CPU_GUESTNICE] = "kernel.all.cpu.guest_nice",
|
|
|
|
[PCP_PERCPU_USER] = "kernel.percpu.cpu.user",
|
|
|
|
[PCP_PERCPU_NICE] = "kernel.percpu.cpu.nice",
|
|
|
|
[PCP_PERCPU_SYSTEM] = "kernel.percpu.cpu.sys",
|
|
|
|
[PCP_PERCPU_IDLE] = "kernel.percpu.cpu.idle",
|
|
|
|
[PCP_PERCPU_IOWAIT] = "kernel.percpu.cpu.wait.total",
|
|
|
|
[PCP_PERCPU_IRQ] = "kernel.percpu.cpu.intr",
|
|
|
|
[PCP_PERCPU_SOFTIRQ] = "kernel.percpu.cpu.irq.soft",
|
|
|
|
[PCP_PERCPU_STEAL] = "kernel.percpu.cpu.steal",
|
|
|
|
[PCP_PERCPU_GUEST] = "kernel.percpu.cpu.guest",
|
|
|
|
[PCP_PERCPU_GUESTNICE] = "kernel.percpu.cpu.guest_nice",
|
|
|
|
[PCP_MEM_TOTAL] = "mem.physmem",
|
|
|
|
[PCP_MEM_FREE] = "mem.util.free",
|
|
|
|
[PCP_MEM_AVAILABLE] = "mem.util.available",
|
|
|
|
[PCP_MEM_BUFFERS] = "mem.util.bufmem",
|
|
|
|
[PCP_MEM_CACHED] = "mem.util.cached",
|
2021-07-28 23:44:03 +00:00
|
|
|
[PCP_MEM_SHARED] = "mem.util.shmem",
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
[PCP_MEM_SRECLAIM] = "mem.util.slabReclaimable",
|
|
|
|
[PCP_MEM_SWAPCACHED] = "mem.util.swapCached",
|
|
|
|
[PCP_MEM_SWAPTOTAL] = "mem.util.swapTotal",
|
|
|
|
[PCP_MEM_SWAPFREE] = "mem.util.swapFree",
|
|
|
|
[PCP_DISK_READB] = "disk.all.read_bytes",
|
|
|
|
[PCP_DISK_WRITEB] = "disk.all.write_bytes",
|
|
|
|
[PCP_DISK_ACTIVE] = "disk.all.avactive",
|
|
|
|
[PCP_NET_RECVB] = "network.all.in.bytes",
|
|
|
|
[PCP_NET_SENDB] = "network.all.out.bytes",
|
|
|
|
[PCP_NET_RECVP] = "network.all.in.packets",
|
|
|
|
[PCP_NET_SENDP] = "network.all.out.packets",
|
|
|
|
|
|
|
|
[PCP_PSI_CPUSOME] = "kernel.all.pressure.cpu.some.avg",
|
|
|
|
[PCP_PSI_IOSOME] = "kernel.all.pressure.io.some.avg",
|
|
|
|
[PCP_PSI_IOFULL] = "kernel.all.pressure.io.full.avg",
|
|
|
|
[PCP_PSI_MEMSOME] = "kernel.all.pressure.memory.some.avg",
|
|
|
|
[PCP_PSI_MEMFULL] = "kernel.all.pressure.memory.full.avg",
|
|
|
|
|
2021-02-22 05:45:44 +00:00
|
|
|
[PCP_ZFS_ARC_ANON_SIZE] = "zfs.arc.anon_size",
|
|
|
|
[PCP_ZFS_ARC_BONUS_SIZE] = "zfs.arc.bonus_size",
|
|
|
|
[PCP_ZFS_ARC_COMPRESSED_SIZE] = "zfs.arc.compressed_size",
|
|
|
|
[PCP_ZFS_ARC_UNCOMPRESSED_SIZE] = "zfs.arc.uncompressed_size",
|
|
|
|
[PCP_ZFS_ARC_C_MAX] = "zfs.arc.c_max",
|
|
|
|
[PCP_ZFS_ARC_DBUF_SIZE] = "zfs.arc.dbuf_size",
|
|
|
|
[PCP_ZFS_ARC_DNODE_SIZE] = "zfs.arc.dnode_size",
|
|
|
|
[PCP_ZFS_ARC_HDR_SIZE] = "zfs.arc.hdr_size",
|
|
|
|
[PCP_ZFS_ARC_MFU_SIZE] = "zfs.arc.mfu.size",
|
|
|
|
[PCP_ZFS_ARC_MRU_SIZE] = "zfs.arc.mru.size",
|
|
|
|
[PCP_ZFS_ARC_SIZE] = "zfs.arc.size",
|
|
|
|
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
[PCP_ZRAM_CAPACITY] = "zram.capacity",
|
|
|
|
[PCP_ZRAM_ORIGINAL] = "zram.mm_stat.data_size.original",
|
|
|
|
[PCP_ZRAM_COMPRESSED] = "zram.mm_stat.data_size.compressed",
|
|
|
|
|
|
|
|
[PCP_PROC_PID] = "proc.psinfo.pid",
|
|
|
|
[PCP_PROC_PPID] = "proc.psinfo.ppid",
|
|
|
|
[PCP_PROC_TGID] = "proc.psinfo.tgid",
|
|
|
|
[PCP_PROC_PGRP] = "proc.psinfo.pgrp",
|
|
|
|
[PCP_PROC_SESSION] = "proc.psinfo.session",
|
|
|
|
[PCP_PROC_STATE] = "proc.psinfo.sname",
|
|
|
|
[PCP_PROC_TTY] = "proc.psinfo.tty",
|
|
|
|
[PCP_PROC_TTYPGRP] = "proc.psinfo.tty_pgrp",
|
|
|
|
[PCP_PROC_MINFLT] = "proc.psinfo.minflt",
|
|
|
|
[PCP_PROC_MAJFLT] = "proc.psinfo.maj_flt",
|
|
|
|
[PCP_PROC_CMINFLT] = "proc.psinfo.cmin_flt",
|
|
|
|
[PCP_PROC_CMAJFLT] = "proc.psinfo.cmaj_flt",
|
|
|
|
[PCP_PROC_UTIME] = "proc.psinfo.utime",
|
|
|
|
[PCP_PROC_STIME] = "proc.psinfo.stime",
|
|
|
|
[PCP_PROC_CUTIME] = "proc.psinfo.cutime",
|
|
|
|
[PCP_PROC_CSTIME] = "proc.psinfo.cstime",
|
|
|
|
[PCP_PROC_PRIORITY] = "proc.psinfo.priority",
|
|
|
|
[PCP_PROC_NICE] = "proc.psinfo.nice",
|
|
|
|
[PCP_PROC_THREADS] = "proc.psinfo.threads",
|
|
|
|
[PCP_PROC_STARTTIME] = "proc.psinfo.start_time",
|
|
|
|
[PCP_PROC_PROCESSOR] = "proc.psinfo.processor",
|
|
|
|
[PCP_PROC_CMD] = "proc.psinfo.cmd",
|
|
|
|
[PCP_PROC_PSARGS] = "proc.psinfo.psargs",
|
|
|
|
[PCP_PROC_CGROUPS] = "proc.psinfo.cgroups",
|
|
|
|
[PCP_PROC_OOMSCORE] = "proc.psinfo.oom_score",
|
|
|
|
[PCP_PROC_VCTXSW] = "proc.psinfo.vctxsw",
|
|
|
|
[PCP_PROC_NVCTXSW] = "proc.psinfo.nvctxsw",
|
|
|
|
[PCP_PROC_LABELS] = "proc.psinfo.labels",
|
|
|
|
[PCP_PROC_ENVIRON] = "proc.psinfo.environ",
|
|
|
|
[PCP_PROC_TTYNAME] = "proc.psinfo.ttyname",
|
2021-05-27 06:05:48 +00:00
|
|
|
[PCP_PROC_EXE] = "proc.psinfo.exe",
|
|
|
|
[PCP_PROC_CWD] = "proc.psinfo.cwd",
|
2021-08-06 06:45:30 +00:00
|
|
|
[PCP_PROC_AUTOGROUP_ID] = "proc.autogroup.id",
|
|
|
|
[PCP_PROC_AUTOGROUP_NICE] = "proc.autogroup.nice",
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
[PCP_PROC_ID_UID] = "proc.id.uid",
|
|
|
|
[PCP_PROC_ID_USER] = "proc.id.uid_nm",
|
|
|
|
[PCP_PROC_IO_RCHAR] = "proc.io.rchar",
|
|
|
|
[PCP_PROC_IO_WCHAR] = "proc.io.wchar",
|
|
|
|
[PCP_PROC_IO_SYSCR] = "proc.io.syscr",
|
|
|
|
[PCP_PROC_IO_SYSCW] = "proc.io.syscw",
|
|
|
|
[PCP_PROC_IO_READB] = "proc.io.read_bytes",
|
|
|
|
[PCP_PROC_IO_WRITEB] = "proc.io.write_bytes",
|
|
|
|
[PCP_PROC_IO_CANCELLED] = "proc.io.cancelled_write_bytes",
|
|
|
|
[PCP_PROC_MEM_SIZE] = "proc.memory.size",
|
|
|
|
[PCP_PROC_MEM_RSS] = "proc.memory.rss",
|
|
|
|
[PCP_PROC_MEM_SHARE] = "proc.memory.share",
|
|
|
|
[PCP_PROC_MEM_TEXTRS] = "proc.memory.textrss",
|
|
|
|
[PCP_PROC_MEM_LIBRS] = "proc.memory.librss",
|
|
|
|
[PCP_PROC_MEM_DATRS] = "proc.memory.datrss",
|
|
|
|
[PCP_PROC_MEM_DIRTY] = "proc.memory.dirty",
|
|
|
|
[PCP_PROC_SMAPS_PSS] = "proc.smaps.pss",
|
|
|
|
[PCP_PROC_SMAPS_SWAP] = "proc.smaps.swap",
|
|
|
|
[PCP_PROC_SMAPS_SWAPPSS] = "proc.smaps.swappss",
|
|
|
|
|
|
|
|
[PCP_METRIC_COUNT] = NULL
|
|
|
|
};
|
|
|
|
|
2021-08-14 21:30:19 +00:00
|
|
|
size_t Platform_addMetric(PCPMetric id, const char* name) {
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
unsigned int i = (unsigned int)id;
|
|
|
|
|
2021-06-23 07:44:56 +00:00
|
|
|
if (i >= PCP_METRIC_COUNT && i >= pcp->totalMetrics) {
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
/* added via configuration files */
|
PCP: support for 'dynamic columns' added at runtime
Implements support for arbitrary Performance Co-Pilot
metrics with per-process instance domains to form new
htop columns. The column-to-metric mappings are setup
using configuration files which will be documented via
man pages as part of a follow-up commit.
We provide an initial set of column configurations so
as to provide new capabilities to pcp-htop: including
configs for containers, open fd counts, scheduler run
queue time, tcp/udp bytes/calls sent/recv, delay acct,
virtual machine guests, detailed virtual memory, swap.
Note there is a change to the configuration file path
resolution algorithm introduced for 'dynamic meters'.
First, look in any custom PCP_HTOP_DIR location. Then
iterate, in priority order, users home directory, then
local sysadmins files in /etc/pcp/htop, then readonly
configuration files below /usr/share/pcp/htop. This
final location becomes the preferred place for our own
shipped meter and column files.
The Settings file (htoprc) writing code is updated to
not using the numeric identifier for dynamic columns.
The same strategy used for dynamic meters is used here
where we write Dynamic(name) so the name can be setup
once more at start. Regular (static) columns writing
to htoprc - i.e. numerically indexed - is unchanged.
2021-07-11 01:11:29 +00:00
|
|
|
size_t j = pcp->totalMetrics + 1;
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
pcp->fetch = xRealloc(pcp->fetch, j * sizeof(pmID));
|
|
|
|
pcp->pmids = xRealloc(pcp->pmids, j * sizeof(pmID));
|
|
|
|
pcp->names = xRealloc(pcp->names, j * sizeof(char*));
|
|
|
|
pcp->descs = xRealloc(pcp->descs, j * sizeof(pmDesc));
|
|
|
|
memset(&pcp->descs[i], 0, sizeof(pmDesc));
|
|
|
|
}
|
|
|
|
|
|
|
|
pcp->pmids[i] = pcp->fetch[i] = PM_ID_NULL;
|
|
|
|
pcp->names[i] = name;
|
2021-06-23 07:44:56 +00:00
|
|
|
return ++pcp->totalMetrics;
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
}
|
|
|
|
|
2021-03-25 06:24:14 +00:00
|
|
|
/* global state from the environment and command line arguments */
|
|
|
|
pmOptions opts;
|
|
|
|
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
void Platform_init(void) {
|
2021-04-08 00:13:43 +00:00
|
|
|
const char* source;
|
|
|
|
if (opts.context == PM_CONTEXT_ARCHIVE) {
|
|
|
|
source = opts.archives[0];
|
|
|
|
} else if (opts.context == PM_CONTEXT_HOST) {
|
|
|
|
source = opts.nhosts > 0 ? opts.hosts[0] : "local:";
|
|
|
|
} else {
|
|
|
|
opts.context = PM_CONTEXT_HOST;
|
|
|
|
source = "local:";
|
|
|
|
}
|
2021-03-25 06:24:14 +00:00
|
|
|
|
|
|
|
int sts;
|
2021-04-08 00:13:43 +00:00
|
|
|
sts = pmNewContext(opts.context, source);
|
2021-03-25 06:24:14 +00:00
|
|
|
/* with no host requested, fallback to PM_CONTEXT_LOCAL shared libraries */
|
2021-04-08 00:13:43 +00:00
|
|
|
if (sts < 0 && opts.context == PM_CONTEXT_HOST && opts.nhosts == 0) {
|
|
|
|
opts.context = PM_CONTEXT_LOCAL;
|
|
|
|
sts = pmNewContext(opts.context, NULL);
|
|
|
|
}
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
if (sts < 0) {
|
|
|
|
fprintf(stderr, "Cannot setup PCP metric source: %s\n", pmErrStr(sts));
|
|
|
|
exit(1);
|
|
|
|
}
|
2021-03-25 06:24:14 +00:00
|
|
|
/* setup timezones and other general startup preparation completion */
|
2021-04-08 03:15:59 +00:00
|
|
|
if (pmGetContextOptions(sts, &opts) < 0 || opts.errors) {
|
2021-03-25 06:24:14 +00:00
|
|
|
pmflush();
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
pcp = xCalloc(1, sizeof(Platform));
|
|
|
|
pcp->context = sts;
|
|
|
|
pcp->fetch = xCalloc(PCP_METRIC_COUNT, sizeof(pmID));
|
|
|
|
pcp->pmids = xCalloc(PCP_METRIC_COUNT, sizeof(pmID));
|
|
|
|
pcp->names = xCalloc(PCP_METRIC_COUNT, sizeof(char*));
|
|
|
|
pcp->descs = xCalloc(PCP_METRIC_COUNT, sizeof(pmDesc));
|
|
|
|
|
2021-04-08 00:13:43 +00:00
|
|
|
if (opts.context == PM_CONTEXT_ARCHIVE) {
|
|
|
|
gettimeofday(&pcp->offset, NULL);
|
|
|
|
pmtimevalDec(&pcp->offset, &opts.start);
|
|
|
|
}
|
|
|
|
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
for (unsigned int i = 0; i < PCP_METRIC_COUNT; i++)
|
|
|
|
Platform_addMetric(i, Platform_metricNames[i]);
|
2021-06-23 07:44:56 +00:00
|
|
|
pcp->meters.offset = PCP_METRIC_COUNT;
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
|
2021-06-23 07:44:56 +00:00
|
|
|
PCPDynamicMeters_init(&pcp->meters);
|
|
|
|
|
PCP: support for 'dynamic columns' added at runtime
Implements support for arbitrary Performance Co-Pilot
metrics with per-process instance domains to form new
htop columns. The column-to-metric mappings are setup
using configuration files which will be documented via
man pages as part of a follow-up commit.
We provide an initial set of column configurations so
as to provide new capabilities to pcp-htop: including
configs for containers, open fd counts, scheduler run
queue time, tcp/udp bytes/calls sent/recv, delay acct,
virtual machine guests, detailed virtual memory, swap.
Note there is a change to the configuration file path
resolution algorithm introduced for 'dynamic meters'.
First, look in any custom PCP_HTOP_DIR location. Then
iterate, in priority order, users home directory, then
local sysadmins files in /etc/pcp/htop, then readonly
configuration files below /usr/share/pcp/htop. This
final location becomes the preferred place for our own
shipped meter and column files.
The Settings file (htoprc) writing code is updated to
not using the numeric identifier for dynamic columns.
The same strategy used for dynamic meters is used here
where we write Dynamic(name) so the name can be setup
once more at start. Regular (static) columns writing
to htoprc - i.e. numerically indexed - is unchanged.
2021-07-11 01:11:29 +00:00
|
|
|
pcp->columns.offset = PCP_METRIC_COUNT + pcp->meters.cursor;
|
|
|
|
PCPDynamicColumns_init(&pcp->columns);
|
|
|
|
|
2021-06-23 07:44:56 +00:00
|
|
|
sts = pmLookupName(pcp->totalMetrics, pcp->names, pcp->pmids);
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
if (sts < 0) {
|
|
|
|
fprintf(stderr, "Error: cannot lookup metric names: %s\n", pmErrStr(sts));
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
PCP: support for 'dynamic columns' added at runtime
Implements support for arbitrary Performance Co-Pilot
metrics with per-process instance domains to form new
htop columns. The column-to-metric mappings are setup
using configuration files which will be documented via
man pages as part of a follow-up commit.
We provide an initial set of column configurations so
as to provide new capabilities to pcp-htop: including
configs for containers, open fd counts, scheduler run
queue time, tcp/udp bytes/calls sent/recv, delay acct,
virtual machine guests, detailed virtual memory, swap.
Note there is a change to the configuration file path
resolution algorithm introduced for 'dynamic meters'.
First, look in any custom PCP_HTOP_DIR location. Then
iterate, in priority order, users home directory, then
local sysadmins files in /etc/pcp/htop, then readonly
configuration files below /usr/share/pcp/htop. This
final location becomes the preferred place for our own
shipped meter and column files.
The Settings file (htoprc) writing code is updated to
not using the numeric identifier for dynamic columns.
The same strategy used for dynamic meters is used here
where we write Dynamic(name) so the name can be setup
once more at start. Regular (static) columns writing
to htoprc - i.e. numerically indexed - is unchanged.
2021-07-11 01:11:29 +00:00
|
|
|
for (size_t i = 0; i < pcp->totalMetrics; i++) {
|
|
|
|
pcp->fetch[i] = PM_ID_NULL; /* default is to not sample */
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
|
|
|
|
/* expect some metrics to be missing - e.g. PMDA not available */
|
|
|
|
if (pcp->pmids[i] == PM_ID_NULL)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
sts = pmLookupDesc(pcp->pmids[i], &pcp->descs[i]);
|
|
|
|
if (sts < 0) {
|
|
|
|
if (pmDebugOptions.appl0)
|
|
|
|
fprintf(stderr, "Error: cannot lookup metric %s(%s): %s\n",
|
|
|
|
pcp->names[i], pmIDStr(pcp->pmids[i]), pmErrStr(sts));
|
|
|
|
pcp->pmids[i] = PM_ID_NULL;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* set proc.control.perclient.threads to 1 for live contexts */
|
2021-08-14 21:30:19 +00:00
|
|
|
PCPMetric_enableThreads();
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
|
|
|
|
/* extract values needed for setup - e.g. cpu count, pid_max */
|
2021-08-14 21:30:19 +00:00
|
|
|
PCPMetric_enable(PCP_PID_MAX, true);
|
|
|
|
PCPMetric_enable(PCP_BOOTTIME, true);
|
|
|
|
PCPMetric_enable(PCP_HINV_NCPU, true);
|
|
|
|
PCPMetric_enable(PCP_PERCPU_SYSTEM, true);
|
|
|
|
PCPMetric_enable(PCP_UNAME_SYSNAME, true);
|
|
|
|
PCPMetric_enable(PCP_UNAME_RELEASE, true);
|
|
|
|
PCPMetric_enable(PCP_UNAME_MACHINE, true);
|
|
|
|
PCPMetric_enable(PCP_UNAME_DISTRO, true);
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
|
PCP: support for 'dynamic columns' added at runtime
Implements support for arbitrary Performance Co-Pilot
metrics with per-process instance domains to form new
htop columns. The column-to-metric mappings are setup
using configuration files which will be documented via
man pages as part of a follow-up commit.
We provide an initial set of column configurations so
as to provide new capabilities to pcp-htop: including
configs for containers, open fd counts, scheduler run
queue time, tcp/udp bytes/calls sent/recv, delay acct,
virtual machine guests, detailed virtual memory, swap.
Note there is a change to the configuration file path
resolution algorithm introduced for 'dynamic meters'.
First, look in any custom PCP_HTOP_DIR location. Then
iterate, in priority order, users home directory, then
local sysadmins files in /etc/pcp/htop, then readonly
configuration files below /usr/share/pcp/htop. This
final location becomes the preferred place for our own
shipped meter and column files.
The Settings file (htoprc) writing code is updated to
not using the numeric identifier for dynamic columns.
The same strategy used for dynamic meters is used here
where we write Dynamic(name) so the name can be setup
once more at start. Regular (static) columns writing
to htoprc - i.e. numerically indexed - is unchanged.
2021-07-11 01:11:29 +00:00
|
|
|
for (size_t i = pcp->columns.offset; i < pcp->columns.offset + pcp->columns.count; i++)
|
2021-08-14 21:30:19 +00:00
|
|
|
PCPMetric_enable(i, true);
|
PCP: support for 'dynamic columns' added at runtime
Implements support for arbitrary Performance Co-Pilot
metrics with per-process instance domains to form new
htop columns. The column-to-metric mappings are setup
using configuration files which will be documented via
man pages as part of a follow-up commit.
We provide an initial set of column configurations so
as to provide new capabilities to pcp-htop: including
configs for containers, open fd counts, scheduler run
queue time, tcp/udp bytes/calls sent/recv, delay acct,
virtual machine guests, detailed virtual memory, swap.
Note there is a change to the configuration file path
resolution algorithm introduced for 'dynamic meters'.
First, look in any custom PCP_HTOP_DIR location. Then
iterate, in priority order, users home directory, then
local sysadmins files in /etc/pcp/htop, then readonly
configuration files below /usr/share/pcp/htop. This
final location becomes the preferred place for our own
shipped meter and column files.
The Settings file (htoprc) writing code is updated to
not using the numeric identifier for dynamic columns.
The same strategy used for dynamic meters is used here
where we write Dynamic(name) so the name can be setup
once more at start. Regular (static) columns writing
to htoprc - i.e. numerically indexed - is unchanged.
2021-07-11 01:11:29 +00:00
|
|
|
|
2021-08-14 21:30:19 +00:00
|
|
|
PCPMetric_fetch(NULL);
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
|
2021-08-14 21:30:19 +00:00
|
|
|
for (PCPMetric metric = 0; metric < PCP_PROC_PID; metric++)
|
|
|
|
PCPMetric_enable(metric, true);
|
|
|
|
PCPMetric_enable(PCP_PID_MAX, false); /* needed one time only */
|
|
|
|
PCPMetric_enable(PCP_BOOTTIME, false);
|
|
|
|
PCPMetric_enable(PCP_UNAME_SYSNAME, false);
|
|
|
|
PCPMetric_enable(PCP_UNAME_RELEASE, false);
|
|
|
|
PCPMetric_enable(PCP_UNAME_MACHINE, false);
|
|
|
|
PCPMetric_enable(PCP_UNAME_DISTRO, false);
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
|
|
|
|
/* first sample (fetch) performed above, save constants */
|
|
|
|
Platform_getBootTime();
|
2021-03-05 05:35:32 +00:00
|
|
|
Platform_getRelease(0);
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
Platform_getMaxCPU();
|
|
|
|
Platform_getMaxPid();
|
|
|
|
}
|
|
|
|
|
2021-09-03 02:11:31 +00:00
|
|
|
void Platform_dynamicColumnsDone(Hashtable* columns) {
|
|
|
|
PCPDynamicColumns_done(columns);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Platform_dynamicMetersDone(Hashtable* meters) {
|
|
|
|
PCPDynamicMeters_done(meters);
|
|
|
|
}
|
|
|
|
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
void Platform_done(void) {
|
|
|
|
pmDestroyContext(pcp->context);
|
2021-06-11 03:30:31 +00:00
|
|
|
if (pcp->result)
|
|
|
|
pmFreeResult(pcp->result);
|
2021-06-10 01:25:31 +00:00
|
|
|
free(pcp->release);
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
free(pcp->fetch);
|
|
|
|
free(pcp->pmids);
|
|
|
|
free(pcp->names);
|
|
|
|
free(pcp->descs);
|
|
|
|
free(pcp);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Platform_setBindings(Htop_Action* keys) {
|
|
|
|
/* no platform-specific key bindings */
|
|
|
|
(void)keys;
|
|
|
|
}
|
|
|
|
|
|
|
|
int Platform_getUptime(void) {
|
|
|
|
pmAtomValue value;
|
2021-08-14 21:30:19 +00:00
|
|
|
if (PCPMetric_values(PCP_UPTIME, &value, 1, PM_TYPE_32) == NULL)
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
return 0;
|
|
|
|
return value.l;
|
|
|
|
}
|
|
|
|
|
|
|
|
void Platform_getLoadAverage(double* one, double* five, double* fifteen) {
|
|
|
|
*one = *five = *fifteen = 0.0;
|
|
|
|
|
|
|
|
pmAtomValue values[3] = {0};
|
2021-08-14 21:30:19 +00:00
|
|
|
if (PCPMetric_values(PCP_LOAD_AVERAGE, values, 3, PM_TYPE_DOUBLE) != NULL) {
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
*one = values[0].d;
|
|
|
|
*five = values[1].d;
|
|
|
|
*fifteen = values[2].d;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-08-17 04:41:55 +00:00
|
|
|
unsigned int Platform_getMaxCPU(void) {
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
if (pcp->ncpu)
|
|
|
|
return pcp->ncpu;
|
|
|
|
|
|
|
|
pmAtomValue value;
|
2021-08-17 04:41:55 +00:00
|
|
|
if (PCPMetric_values(PCP_HINV_NCPU, &value, 1, PM_TYPE_U32) != NULL)
|
|
|
|
pcp->ncpu = value.ul;
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
else
|
2021-08-17 04:41:55 +00:00
|
|
|
pcp->ncpu = 1;
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
return pcp->ncpu;
|
|
|
|
}
|
|
|
|
|
|
|
|
int Platform_getMaxPid(void) {
|
|
|
|
if (pcp->pidmax)
|
|
|
|
return pcp->pidmax;
|
|
|
|
|
|
|
|
pmAtomValue value;
|
2021-08-14 21:30:19 +00:00
|
|
|
if (PCPMetric_values(PCP_PID_MAX, &value, 1, PM_TYPE_32) == NULL)
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
return -1;
|
|
|
|
pcp->pidmax = value.l;
|
|
|
|
return pcp->pidmax;
|
|
|
|
}
|
|
|
|
|
|
|
|
long long Platform_getBootTime(void) {
|
|
|
|
if (pcp->btime)
|
|
|
|
return pcp->btime;
|
|
|
|
|
|
|
|
pmAtomValue value;
|
2021-08-14 21:30:19 +00:00
|
|
|
if (PCPMetric_values(PCP_BOOTTIME, &value, 1, PM_TYPE_64) != NULL)
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
pcp->btime = value.ll;
|
|
|
|
return pcp->btime;
|
|
|
|
}
|
|
|
|
|
|
|
|
static double Platform_setOneCPUValues(Meter* this, pmAtomValue* values) {
|
|
|
|
|
|
|
|
unsigned long long value = values[CPU_TOTAL_PERIOD].ull;
|
|
|
|
double total = (double) (value == 0 ? 1 : value);
|
|
|
|
double percent;
|
|
|
|
|
|
|
|
double* v = this->values;
|
|
|
|
v[CPU_METER_NICE] = values[CPU_NICE_PERIOD].ull / total * 100.0;
|
|
|
|
v[CPU_METER_NORMAL] = values[CPU_USER_PERIOD].ull / total * 100.0;
|
|
|
|
if (this->pl->settings->detailedCPUTime) {
|
|
|
|
v[CPU_METER_KERNEL] = values[CPU_SYSTEM_PERIOD].ull / total * 100.0;
|
|
|
|
v[CPU_METER_IRQ] = values[CPU_IRQ_PERIOD].ull / total * 100.0;
|
|
|
|
v[CPU_METER_SOFTIRQ] = values[CPU_SOFTIRQ_PERIOD].ull / total * 100.0;
|
|
|
|
v[CPU_METER_STEAL] = values[CPU_STEAL_PERIOD].ull / total * 100.0;
|
|
|
|
v[CPU_METER_GUEST] = values[CPU_GUEST_PERIOD].ull / total * 100.0;
|
|
|
|
v[CPU_METER_IOWAIT] = values[CPU_IOWAIT_PERIOD].ull / total * 100.0;
|
|
|
|
this->curItems = 8;
|
|
|
|
if (this->pl->settings->accountGuestInCPUMeter)
|
|
|
|
percent = v[0] + v[1] + v[2] + v[3] + v[4] + v[5] + v[6];
|
|
|
|
else
|
|
|
|
percent = v[0] + v[1] + v[2] + v[3] + v[4];
|
|
|
|
} else {
|
|
|
|
v[2] = values[CPU_SYSTEM_ALL_PERIOD].ull / total * 100.0;
|
|
|
|
value = values[CPU_STEAL_PERIOD].ull + values[CPU_GUEST_PERIOD].ull;
|
|
|
|
v[3] = value / total * 100.0;
|
|
|
|
this->curItems = 4;
|
|
|
|
percent = v[0] + v[1] + v[2] + v[3];
|
|
|
|
}
|
|
|
|
percent = CLAMP(percent, 0.0, 100.0);
|
|
|
|
if (isnan(percent))
|
|
|
|
percent = 0.0;
|
|
|
|
|
|
|
|
v[CPU_METER_FREQUENCY] = values[CPU_FREQUENCY].d;
|
|
|
|
v[CPU_METER_TEMPERATURE] = NAN;
|
|
|
|
|
|
|
|
return percent;
|
|
|
|
}
|
|
|
|
|
|
|
|
double Platform_setCPUValues(Meter* this, int cpu) {
|
|
|
|
const PCPProcessList* pl = (const PCPProcessList*) this->pl;
|
PCP: support for 'dynamic columns' added at runtime
Implements support for arbitrary Performance Co-Pilot
metrics with per-process instance domains to form new
htop columns. The column-to-metric mappings are setup
using configuration files which will be documented via
man pages as part of a follow-up commit.
We provide an initial set of column configurations so
as to provide new capabilities to pcp-htop: including
configs for containers, open fd counts, scheduler run
queue time, tcp/udp bytes/calls sent/recv, delay acct,
virtual machine guests, detailed virtual memory, swap.
Note there is a change to the configuration file path
resolution algorithm introduced for 'dynamic meters'.
First, look in any custom PCP_HTOP_DIR location. Then
iterate, in priority order, users home directory, then
local sysadmins files in /etc/pcp/htop, then readonly
configuration files below /usr/share/pcp/htop. This
final location becomes the preferred place for our own
shipped meter and column files.
The Settings file (htoprc) writing code is updated to
not using the numeric identifier for dynamic columns.
The same strategy used for dynamic meters is used here
where we write Dynamic(name) so the name can be setup
once more at start. Regular (static) columns writing
to htoprc - i.e. numerically indexed - is unchanged.
2021-07-11 01:11:29 +00:00
|
|
|
if (cpu <= 0) /* use aggregate values */
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
return Platform_setOneCPUValues(this, pl->cpu);
|
|
|
|
return Platform_setOneCPUValues(this, pl->percpu[cpu - 1]);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Platform_setMemoryValues(Meter* this) {
|
|
|
|
const ProcessList* pl = this->pl;
|
2021-02-22 05:45:44 +00:00
|
|
|
const PCPProcessList* ppl = (const PCPProcessList*) pl;
|
2021-03-16 22:54:15 +00:00
|
|
|
|
|
|
|
this->total = pl->totalMem;
|
|
|
|
this->values[0] = pl->usedMem;
|
|
|
|
this->values[1] = pl->buffersMem;
|
|
|
|
this->values[2] = pl->sharedMem;
|
|
|
|
this->values[3] = pl->cachedMem;
|
|
|
|
this->values[4] = pl->availableMem;
|
2021-02-22 05:45:44 +00:00
|
|
|
|
|
|
|
if (ppl->zfs.enabled != 0) {
|
|
|
|
this->values[0] -= ppl->zfs.size;
|
2021-03-16 22:54:15 +00:00
|
|
|
this->values[3] += ppl->zfs.size;
|
2021-02-22 05:45:44 +00:00
|
|
|
}
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void Platform_setSwapValues(Meter* this) {
|
|
|
|
const ProcessList* pl = this->pl;
|
|
|
|
this->total = pl->totalSwap;
|
|
|
|
this->values[0] = pl->usedSwap;
|
|
|
|
this->values[1] = pl->cachedSwap;
|
|
|
|
}
|
|
|
|
|
|
|
|
void Platform_setZramValues(Meter* this) {
|
2021-08-14 21:30:19 +00:00
|
|
|
int i, count = PCPMetric_instanceCount(PCP_ZRAM_CAPACITY);
|
2021-02-22 05:52:32 +00:00
|
|
|
if (!count) {
|
|
|
|
this->total = 0;
|
|
|
|
this->values[0] = 0;
|
|
|
|
this->values[1] = 0;
|
2021-02-22 05:50:39 +00:00
|
|
|
return;
|
2021-02-22 05:52:32 +00:00
|
|
|
}
|
2021-02-22 05:50:39 +00:00
|
|
|
|
2021-07-09 02:42:36 +00:00
|
|
|
pmAtomValue* values = xCalloc(count, sizeof(pmAtomValue));
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
ZramStats stats = {0};
|
|
|
|
|
2021-08-14 21:30:19 +00:00
|
|
|
if (PCPMetric_values(PCP_ZRAM_CAPACITY, values, count, PM_TYPE_U64)) {
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
for (i = 0; i < count; i++)
|
2021-07-14 17:15:09 +00:00
|
|
|
stats.totalZram += values[i].ull;
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
}
|
2021-08-14 21:30:19 +00:00
|
|
|
if (PCPMetric_values(PCP_ZRAM_ORIGINAL, values, count, PM_TYPE_U64)) {
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
for (i = 0; i < count; i++)
|
2021-07-14 17:15:09 +00:00
|
|
|
stats.usedZramOrig += values[i].ull;
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
}
|
2021-08-14 21:30:19 +00:00
|
|
|
if (PCPMetric_values(PCP_ZRAM_COMPRESSED, values, count, PM_TYPE_U64)) {
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
for (i = 0; i < count; i++)
|
2021-07-14 17:15:09 +00:00
|
|
|
stats.usedZramComp += values[i].ull;
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
free(values);
|
|
|
|
|
|
|
|
this->total = stats.totalZram;
|
|
|
|
this->values[0] = stats.usedZramComp;
|
|
|
|
this->values[1] = stats.usedZramOrig;
|
|
|
|
}
|
|
|
|
|
2021-02-22 05:45:44 +00:00
|
|
|
void Platform_setZfsArcValues(Meter* this) {
|
|
|
|
const PCPProcessList* ppl = (const PCPProcessList*) this->pl;
|
|
|
|
|
|
|
|
ZfsArcMeter_readStats(this, &(ppl->zfs));
|
|
|
|
}
|
|
|
|
|
|
|
|
void Platform_setZfsCompressedArcValues(Meter* this) {
|
|
|
|
const PCPProcessList* ppl = (const PCPProcessList*) this->pl;
|
|
|
|
|
|
|
|
ZfsCompressedArcMeter_readStats(this, &(ppl->zfs));
|
|
|
|
}
|
|
|
|
|
2021-03-05 05:35:32 +00:00
|
|
|
void Platform_getHostname(char* buffer, size_t size) {
|
2021-07-14 17:15:09 +00:00
|
|
|
const char* hostname = pmGetContextHostName(pcp->context);
|
|
|
|
String_safeStrncpy(buffer, hostname, size);
|
2021-03-05 05:35:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void Platform_getRelease(char** string) {
|
|
|
|
/* fast-path - previously-formatted string */
|
|
|
|
if (string) {
|
|
|
|
*string = pcp->release;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* first call, extract just-sampled values */
|
2021-04-08 03:15:59 +00:00
|
|
|
pmAtomValue sysname, release, machine, distro;
|
2021-08-14 21:30:19 +00:00
|
|
|
if (!PCPMetric_values(PCP_UNAME_SYSNAME, &sysname, 1, PM_TYPE_STRING))
|
2021-04-08 03:15:59 +00:00
|
|
|
sysname.cp = NULL;
|
2021-08-14 21:30:19 +00:00
|
|
|
if (!PCPMetric_values(PCP_UNAME_RELEASE, &release, 1, PM_TYPE_STRING))
|
2021-04-08 03:15:59 +00:00
|
|
|
release.cp = NULL;
|
2021-08-14 21:30:19 +00:00
|
|
|
if (!PCPMetric_values(PCP_UNAME_MACHINE, &machine, 1, PM_TYPE_STRING))
|
2021-04-08 03:15:59 +00:00
|
|
|
machine.cp = NULL;
|
2021-08-14 21:30:19 +00:00
|
|
|
if (!PCPMetric_values(PCP_UNAME_DISTRO, &distro, 1, PM_TYPE_STRING))
|
2021-04-08 03:15:59 +00:00
|
|
|
distro.cp = NULL;
|
2021-03-05 05:35:32 +00:00
|
|
|
|
|
|
|
size_t length = 16; /* padded for formatting characters */
|
2021-04-08 03:15:59 +00:00
|
|
|
if (sysname.cp)
|
|
|
|
length += strlen(sysname.cp);
|
|
|
|
if (release.cp)
|
|
|
|
length += strlen(release.cp);
|
|
|
|
if (machine.cp)
|
|
|
|
length += strlen(machine.cp);
|
|
|
|
if (distro.cp)
|
|
|
|
length += strlen(distro.cp);
|
2021-03-05 05:35:32 +00:00
|
|
|
pcp->release = xCalloc(1, length);
|
|
|
|
|
2021-04-08 03:15:59 +00:00
|
|
|
if (sysname.cp) {
|
|
|
|
strcat(pcp->release, sysname.cp);
|
2021-03-05 05:35:32 +00:00
|
|
|
strcat(pcp->release, " ");
|
|
|
|
}
|
2021-04-08 03:15:59 +00:00
|
|
|
if (release.cp) {
|
|
|
|
strcat(pcp->release, release.cp);
|
2021-03-05 05:35:32 +00:00
|
|
|
strcat(pcp->release, " ");
|
|
|
|
}
|
2021-04-08 03:15:59 +00:00
|
|
|
if (machine.cp) {
|
2021-03-05 05:35:32 +00:00
|
|
|
strcat(pcp->release, "[");
|
2021-04-08 03:15:59 +00:00
|
|
|
strcat(pcp->release, machine.cp);
|
2021-03-05 05:35:32 +00:00
|
|
|
strcat(pcp->release, "] ");
|
|
|
|
}
|
2021-04-08 03:15:59 +00:00
|
|
|
if (distro.cp) {
|
2021-03-05 05:35:32 +00:00
|
|
|
if (pcp->release[0] != '\0') {
|
|
|
|
strcat(pcp->release, "@ ");
|
2021-04-08 03:15:59 +00:00
|
|
|
strcat(pcp->release, distro.cp);
|
2021-03-05 05:35:32 +00:00
|
|
|
} else {
|
2021-04-08 03:15:59 +00:00
|
|
|
strcat(pcp->release, distro.cp);
|
2021-03-05 05:35:32 +00:00
|
|
|
}
|
|
|
|
strcat(pcp->release, " ");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pcp->release) /* cull trailing space */
|
|
|
|
pcp->release[strlen(pcp->release)] = '\0';
|
|
|
|
|
2021-04-08 03:15:59 +00:00
|
|
|
free(distro.cp);
|
|
|
|
free(machine.cp);
|
|
|
|
free(release.cp);
|
|
|
|
free(sysname.cp);
|
2021-03-05 05:35:32 +00:00
|
|
|
}
|
|
|
|
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
char* Platform_getProcessEnv(pid_t pid) {
|
|
|
|
pmAtomValue value;
|
2021-08-14 21:30:19 +00:00
|
|
|
if (!PCPMetric_instance(PCP_PROC_ENVIRON, pid, 0, &value, PM_TYPE_STRING))
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
return NULL;
|
|
|
|
return value.cp;
|
|
|
|
}
|
|
|
|
|
|
|
|
char* Platform_getInodeFilename(pid_t pid, ino_t inode) {
|
|
|
|
(void)pid;
|
|
|
|
(void)inode;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
FileLocks_ProcessData* Platform_getProcessLocks(pid_t pid) {
|
|
|
|
(void)pid;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
void Platform_getPressureStall(const char* file, bool some, double* ten, double* sixty, double* threehundred) {
|
|
|
|
*ten = *sixty = *threehundred = 0;
|
|
|
|
|
2021-08-14 21:30:19 +00:00
|
|
|
PCPMetric metric;
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
if (String_eq(file, "cpu"))
|
|
|
|
metric = PCP_PSI_CPUSOME;
|
|
|
|
else if (String_eq(file, "io"))
|
|
|
|
metric = some ? PCP_PSI_IOSOME : PCP_PSI_IOFULL;
|
|
|
|
else if (String_eq(file, "mem"))
|
|
|
|
metric = some ? PCP_PSI_MEMSOME : PCP_PSI_MEMFULL;
|
|
|
|
else
|
|
|
|
return;
|
|
|
|
|
|
|
|
pmAtomValue values[3] = {0};
|
2021-08-14 21:30:19 +00:00
|
|
|
if (PCPMetric_values(metric, values, 3, PM_TYPE_DOUBLE) != NULL) {
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
*ten = values[0].d;
|
|
|
|
*sixty = values[1].d;
|
|
|
|
*threehundred = values[2].d;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Platform_getDiskIO(DiskIOData* data) {
|
2021-03-05 05:35:32 +00:00
|
|
|
memset(data, 0, sizeof(*data));
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
|
|
|
|
pmAtomValue value;
|
2021-08-14 21:30:19 +00:00
|
|
|
if (PCPMetric_values(PCP_DISK_READB, &value, 1, PM_TYPE_U64) != NULL)
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
data->totalBytesRead = value.ull;
|
2021-08-14 21:30:19 +00:00
|
|
|
if (PCPMetric_values(PCP_DISK_WRITEB, &value, 1, PM_TYPE_U64) != NULL)
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
data->totalBytesWritten = value.ull;
|
2021-08-14 21:30:19 +00:00
|
|
|
if (PCPMetric_values(PCP_DISK_ACTIVE, &value, 1, PM_TYPE_U64) != NULL)
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
data->totalMsTimeSpend = value.ull;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2021-03-05 05:35:32 +00:00
|
|
|
bool Platform_getNetworkIO(NetworkIOData* data) {
|
|
|
|
memset(data, 0, sizeof(*data));
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
|
|
|
|
pmAtomValue value;
|
2021-08-14 21:30:19 +00:00
|
|
|
if (PCPMetric_values(PCP_NET_RECVB, &value, 1, PM_TYPE_U64) != NULL)
|
2021-03-05 05:35:32 +00:00
|
|
|
data->bytesReceived = value.ull;
|
2021-08-14 21:30:19 +00:00
|
|
|
if (PCPMetric_values(PCP_NET_SENDB, &value, 1, PM_TYPE_U64) != NULL)
|
2021-03-05 05:35:32 +00:00
|
|
|
data->bytesTransmitted = value.ull;
|
2021-08-14 21:30:19 +00:00
|
|
|
if (PCPMetric_values(PCP_NET_RECVP, &value, 1, PM_TYPE_U64) != NULL)
|
2021-03-05 05:35:32 +00:00
|
|
|
data->packetsReceived = value.ull;
|
2021-08-14 21:30:19 +00:00
|
|
|
if (PCPMetric_values(PCP_NET_SENDP, &value, 1, PM_TYPE_U64) != NULL)
|
2021-03-05 05:35:32 +00:00
|
|
|
data->packetsTransmitted = value.ull;
|
Add a platform for Performance Co-Pilot (PCP) metrics
This introduces an initial platform for extracting metrics
using the PCP performance metrics API - PMAPI(3). It can
be used via the --enable-pcp=yes configure option.
So far I've added support for live localhost metrics only,
and only using pre-defined metrics already found in htop.
If available, all sampling is performed by pmcd(1) - else,
we fallback to htop doing the metric sampling itself (all
below the PMAPI). When pmcd is used, it may be configured
to run children with elevated privileges, so htop does not
need to be setuid (authentication with pmcd is available).
Additionally, the PMAPI allows us to support archives (for
historical analysis and for automated regression tests in
htop). We'll need platform-specific command line argument
additions, which isn't yet feasible in htop (not difficult
to add though).
The goal of this first version is minimal impact in terms
of modifying the htop codebase, to introduce key ideas in
PCP (metric namespace, metadata, APIs and so on) and give
us something to discuss, experiment with and build on.
2021-02-17 03:43:56 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
void Platform_getBattery(double* level, ACPresence* isOnAC) {
|
|
|
|
*level = NAN;
|
|
|
|
*isOnAC = AC_ERROR;
|
|
|
|
}
|
2021-03-25 06:24:14 +00:00
|
|
|
|
|
|
|
void Platform_longOptionsUsage(ATTR_UNUSED const char* name) {
|
|
|
|
printf(
|
|
|
|
" --host=HOSTSPEC metrics source is PMCD at HOSTSPEC [see PCPIntro(1)]\n"
|
|
|
|
" --hostzone set reporting timezone to local time of metrics source\n"
|
|
|
|
" --timezone=TZ set reporting timezone\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Platform_getLongOption(int opt, ATTR_UNUSED int argc, char** argv) {
|
|
|
|
/* libpcp export without a header definition */
|
2021-07-09 02:42:36 +00:00
|
|
|
extern void __pmAddOptHost(pmOptions*, char*);
|
2021-03-25 06:24:14 +00:00
|
|
|
|
|
|
|
switch (opt) {
|
|
|
|
case PLATFORM_LONGOPT_HOST: /* --host=HOSTSPEC */
|
|
|
|
if (argv[optind][0] == '\0')
|
|
|
|
return false;
|
2021-04-08 00:13:43 +00:00
|
|
|
__pmAddOptHost(&opts, optarg);
|
2021-03-25 06:24:14 +00:00
|
|
|
return true;
|
|
|
|
|
|
|
|
case PLATFORM_LONGOPT_HOSTZONE: /* --hostzone */
|
|
|
|
if (opts.timezone) {
|
|
|
|
pmprintf("%s: at most one of -Z and -z allowed\n", pmGetProgname());
|
|
|
|
opts.errors++;
|
|
|
|
} else {
|
|
|
|
opts.tzflag = 1;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
|
|
|
|
case PLATFORM_LONGOPT_TIMEZONE: /* --timezone=TZ */
|
|
|
|
if (argv[optind][0] == '\0')
|
|
|
|
return false;
|
|
|
|
if (opts.tzflag) {
|
|
|
|
pmprintf("%s: at most one of -Z and -z allowed\n", pmGetProgname());
|
|
|
|
opts.errors++;
|
2021-04-08 00:13:43 +00:00
|
|
|
} else {
|
2021-03-25 06:24:14 +00:00
|
|
|
opts.timezone = optarg;
|
2021-04-08 00:13:43 +00:00
|
|
|
}
|
2021-03-25 06:24:14 +00:00
|
|
|
return true;
|
|
|
|
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
2021-04-08 00:13:43 +00:00
|
|
|
|
|
|
|
void Platform_gettime_realtime(struct timeval* tv, uint64_t* msec) {
|
|
|
|
if (gettimeofday(tv, NULL) == 0) {
|
|
|
|
/* shift by start offset to stay in lock-step with realtime (archives) */
|
|
|
|
if (pcp->offset.tv_sec || pcp->offset.tv_usec)
|
|
|
|
pmtimevalDec(tv, &pcp->offset);
|
|
|
|
*msec = ((uint64_t)tv->tv_sec * 1000) + ((uint64_t)tv->tv_usec / 1000);
|
|
|
|
} else {
|
|
|
|
memset(tv, 0, sizeof(struct timeval));
|
|
|
|
*msec = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void Platform_gettime_monotonic(uint64_t* msec) {
|
2021-07-07 04:00:36 +00:00
|
|
|
if (pcp->result) {
|
|
|
|
struct timeval* tv = &pcp->result->timestamp;
|
|
|
|
*msec = ((uint64_t)tv->tv_sec * 1000) + ((uint64_t)tv->tv_usec / 1000);
|
|
|
|
} else {
|
|
|
|
*msec = 0;
|
|
|
|
}
|
2021-04-08 00:13:43 +00:00
|
|
|
}
|
2021-06-23 07:44:56 +00:00
|
|
|
|
|
|
|
Hashtable* Platform_dynamicMeters(void) {
|
|
|
|
return pcp->meters.table;
|
|
|
|
}
|
|
|
|
|
|
|
|
void Platform_dynamicMeterInit(Meter* meter) {
|
|
|
|
PCPDynamicMeter* this = Hashtable_get(pcp->meters.table, meter->param);
|
|
|
|
if (this)
|
|
|
|
PCPDynamicMeter_enable(this);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Platform_dynamicMeterUpdateValues(Meter* meter) {
|
|
|
|
PCPDynamicMeter* this = Hashtable_get(pcp->meters.table, meter->param);
|
|
|
|
if (this)
|
|
|
|
PCPDynamicMeter_updateValues(this, meter);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Platform_dynamicMeterDisplay(const Meter* meter, RichString* out) {
|
|
|
|
PCPDynamicMeter* this = Hashtable_get(pcp->meters.table, meter->param);
|
|
|
|
if (this)
|
|
|
|
PCPDynamicMeter_display(this, meter, out);
|
|
|
|
}
|
PCP: support for 'dynamic columns' added at runtime
Implements support for arbitrary Performance Co-Pilot
metrics with per-process instance domains to form new
htop columns. The column-to-metric mappings are setup
using configuration files which will be documented via
man pages as part of a follow-up commit.
We provide an initial set of column configurations so
as to provide new capabilities to pcp-htop: including
configs for containers, open fd counts, scheduler run
queue time, tcp/udp bytes/calls sent/recv, delay acct,
virtual machine guests, detailed virtual memory, swap.
Note there is a change to the configuration file path
resolution algorithm introduced for 'dynamic meters'.
First, look in any custom PCP_HTOP_DIR location. Then
iterate, in priority order, users home directory, then
local sysadmins files in /etc/pcp/htop, then readonly
configuration files below /usr/share/pcp/htop. This
final location becomes the preferred place for our own
shipped meter and column files.
The Settings file (htoprc) writing code is updated to
not using the numeric identifier for dynamic columns.
The same strategy used for dynamic meters is used here
where we write Dynamic(name) so the name can be setup
once more at start. Regular (static) columns writing
to htoprc - i.e. numerically indexed - is unchanged.
2021-07-11 01:11:29 +00:00
|
|
|
|
|
|
|
Hashtable* Platform_dynamicColumns(void) {
|
|
|
|
return pcp->columns.table;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char* Platform_dynamicColumnInit(unsigned int key) {
|
|
|
|
PCPDynamicColumn* this = Hashtable_get(pcp->columns.table, key);
|
|
|
|
if (this) {
|
2021-08-14 21:30:19 +00:00
|
|
|
PCPMetric_enable(this->id, true);
|
PCP: support for 'dynamic columns' added at runtime
Implements support for arbitrary Performance Co-Pilot
metrics with per-process instance domains to form new
htop columns. The column-to-metric mappings are setup
using configuration files which will be documented via
man pages as part of a follow-up commit.
We provide an initial set of column configurations so
as to provide new capabilities to pcp-htop: including
configs for containers, open fd counts, scheduler run
queue time, tcp/udp bytes/calls sent/recv, delay acct,
virtual machine guests, detailed virtual memory, swap.
Note there is a change to the configuration file path
resolution algorithm introduced for 'dynamic meters'.
First, look in any custom PCP_HTOP_DIR location. Then
iterate, in priority order, users home directory, then
local sysadmins files in /etc/pcp/htop, then readonly
configuration files below /usr/share/pcp/htop. This
final location becomes the preferred place for our own
shipped meter and column files.
The Settings file (htoprc) writing code is updated to
not using the numeric identifier for dynamic columns.
The same strategy used for dynamic meters is used here
where we write Dynamic(name) so the name can be setup
once more at start. Regular (static) columns writing
to htoprc - i.e. numerically indexed - is unchanged.
2021-07-11 01:11:29 +00:00
|
|
|
if (this->super.caption)
|
|
|
|
return this->super.caption;
|
|
|
|
if (this->super.heading)
|
|
|
|
return this->super.heading;
|
|
|
|
return this->super.name;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Platform_dynamicColumnWriteField(const Process* proc, RichString* str, unsigned int key) {
|
|
|
|
PCPDynamicColumn* this = Hashtable_get(pcp->columns.table, key);
|
|
|
|
if (this) {
|
|
|
|
PCPDynamicColumn_writeField(this, proc, str);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|