2020-02-28 00:06:53 +00:00
|
|
|
.. _psi:
|
|
|
|
|
psi: pressure stall information for CPU, memory, and IO
When systems are overcommitted and resources become contended, it's hard
to tell exactly the impact this has on workload productivity, or how close
the system is to lockups and OOM kills. In particular, when machines work
multiple jobs concurrently, the impact of overcommit in terms of latency
and throughput on the individual job can be enormous.
In order to maximize hardware utilization without sacrificing individual
job health or risk complete machine lockups, this patch implements a way
to quantify resource pressure in the system.
A kernel built with CONFIG_PSI=y creates files in /proc/pressure/ that
expose the percentage of time the system is stalled on CPU, memory, or IO,
respectively. Stall states are aggregate versions of the per-task delay
accounting delays:
cpu: some tasks are runnable but not executing on a CPU
memory: tasks are reclaiming, or waiting for swapin or thrashing cache
io: tasks are waiting for io completions
These percentages of walltime can be thought of as pressure percentages,
and they give a general sense of system health and productivity loss
incurred by resource overcommit. They can also indicate when the system
is approaching lockup scenarios and OOMs.
To do this, psi keeps track of the task states associated with each CPU
and samples the time they spend in stall states. Every 2 seconds, the
samples are averaged across CPUs - weighted by the CPUs' non-idle time to
eliminate artifacts from unused CPUs - and translated into percentages of
walltime. A running average of those percentages is maintained over 10s,
1m, and 5m periods (similar to the loadaverage).
[hannes@cmpxchg.org: doc fixlet, per Randy]
Link: http://lkml.kernel.org/r/20180828205625.GA14030@cmpxchg.org
[hannes@cmpxchg.org: code optimization]
Link: http://lkml.kernel.org/r/20180907175015.GA8479@cmpxchg.org
[hannes@cmpxchg.org: rename psi_clock() to psi_update_work(), per Peter]
Link: http://lkml.kernel.org/r/20180907145404.GB11088@cmpxchg.org
[hannes@cmpxchg.org: fix build]
Link: http://lkml.kernel.org/r/20180913014222.GA2370@cmpxchg.org
Link: http://lkml.kernel.org/r/20180828172258.3185-9-hannes@cmpxchg.org
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Daniel Drake <drake@endlessm.com>
Tested-by: Suren Baghdasaryan <surenb@google.com>
Cc: Christopher Lameter <cl@linux.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Johannes Weiner <jweiner@fb.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Enderborg <peter.enderborg@sony.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Vinayak Menon <vinmenon@codeaurora.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-10-26 22:06:27 +00:00
|
|
|
================================
|
|
|
|
PSI - Pressure Stall Information
|
|
|
|
================================
|
|
|
|
|
|
|
|
:Date: April, 2018
|
|
|
|
:Author: Johannes Weiner <hannes@cmpxchg.org>
|
|
|
|
|
|
|
|
When CPU, memory or IO devices are contended, workloads experience
|
|
|
|
latency spikes, throughput losses, and run the risk of OOM kills.
|
|
|
|
|
|
|
|
Without an accurate measure of such contention, users are forced to
|
|
|
|
either play it safe and under-utilize their hardware resources, or
|
|
|
|
roll the dice and frequently suffer the disruptions resulting from
|
|
|
|
excessive overcommit.
|
|
|
|
|
|
|
|
The psi feature identifies and quantifies the disruptions caused by
|
|
|
|
such resource crunches and the time impact it has on complex workloads
|
|
|
|
or even entire systems.
|
|
|
|
|
|
|
|
Having an accurate measure of productivity losses caused by resource
|
|
|
|
scarcity aids users in sizing workloads to hardware--or provisioning
|
|
|
|
hardware according to workload demand.
|
|
|
|
|
|
|
|
As psi aggregates this information in realtime, systems can be managed
|
|
|
|
dynamically using techniques such as load shedding, migrating jobs to
|
|
|
|
other systems or data centers, or strategically pausing or killing low
|
|
|
|
priority or restartable batch jobs.
|
|
|
|
|
|
|
|
This allows maximizing hardware utilization without sacrificing
|
|
|
|
workload health or risking major disruptions such as OOM kills.
|
|
|
|
|
|
|
|
Pressure interface
|
|
|
|
==================
|
|
|
|
|
|
|
|
Pressure information for each resource is exported through the
|
|
|
|
respective file in /proc/pressure/ -- cpu, memory, and io.
|
|
|
|
|
2022-04-08 12:19:14 +00:00
|
|
|
The format is as such::
|
psi: pressure stall information for CPU, memory, and IO
When systems are overcommitted and resources become contended, it's hard
to tell exactly the impact this has on workload productivity, or how close
the system is to lockups and OOM kills. In particular, when machines work
multiple jobs concurrently, the impact of overcommit in terms of latency
and throughput on the individual job can be enormous.
In order to maximize hardware utilization without sacrificing individual
job health or risk complete machine lockups, this patch implements a way
to quantify resource pressure in the system.
A kernel built with CONFIG_PSI=y creates files in /proc/pressure/ that
expose the percentage of time the system is stalled on CPU, memory, or IO,
respectively. Stall states are aggregate versions of the per-task delay
accounting delays:
cpu: some tasks are runnable but not executing on a CPU
memory: tasks are reclaiming, or waiting for swapin or thrashing cache
io: tasks are waiting for io completions
These percentages of walltime can be thought of as pressure percentages,
and they give a general sense of system health and productivity loss
incurred by resource overcommit. They can also indicate when the system
is approaching lockup scenarios and OOMs.
To do this, psi keeps track of the task states associated with each CPU
and samples the time they spend in stall states. Every 2 seconds, the
samples are averaged across CPUs - weighted by the CPUs' non-idle time to
eliminate artifacts from unused CPUs - and translated into percentages of
walltime. A running average of those percentages is maintained over 10s,
1m, and 5m periods (similar to the loadaverage).
[hannes@cmpxchg.org: doc fixlet, per Randy]
Link: http://lkml.kernel.org/r/20180828205625.GA14030@cmpxchg.org
[hannes@cmpxchg.org: code optimization]
Link: http://lkml.kernel.org/r/20180907175015.GA8479@cmpxchg.org
[hannes@cmpxchg.org: rename psi_clock() to psi_update_work(), per Peter]
Link: http://lkml.kernel.org/r/20180907145404.GB11088@cmpxchg.org
[hannes@cmpxchg.org: fix build]
Link: http://lkml.kernel.org/r/20180913014222.GA2370@cmpxchg.org
Link: http://lkml.kernel.org/r/20180828172258.3185-9-hannes@cmpxchg.org
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Daniel Drake <drake@endlessm.com>
Tested-by: Suren Baghdasaryan <surenb@google.com>
Cc: Christopher Lameter <cl@linux.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Johannes Weiner <jweiner@fb.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Enderborg <peter.enderborg@sony.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Vinayak Menon <vinmenon@codeaurora.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-10-26 22:06:27 +00:00
|
|
|
|
2019-04-17 08:46:08 +00:00
|
|
|
some avg10=0.00 avg60=0.00 avg300=0.00 total=0
|
|
|
|
full avg10=0.00 avg60=0.00 avg300=0.00 total=0
|
psi: pressure stall information for CPU, memory, and IO
When systems are overcommitted and resources become contended, it's hard
to tell exactly the impact this has on workload productivity, or how close
the system is to lockups and OOM kills. In particular, when machines work
multiple jobs concurrently, the impact of overcommit in terms of latency
and throughput on the individual job can be enormous.
In order to maximize hardware utilization without sacrificing individual
job health or risk complete machine lockups, this patch implements a way
to quantify resource pressure in the system.
A kernel built with CONFIG_PSI=y creates files in /proc/pressure/ that
expose the percentage of time the system is stalled on CPU, memory, or IO,
respectively. Stall states are aggregate versions of the per-task delay
accounting delays:
cpu: some tasks are runnable but not executing on a CPU
memory: tasks are reclaiming, or waiting for swapin or thrashing cache
io: tasks are waiting for io completions
These percentages of walltime can be thought of as pressure percentages,
and they give a general sense of system health and productivity loss
incurred by resource overcommit. They can also indicate when the system
is approaching lockup scenarios and OOMs.
To do this, psi keeps track of the task states associated with each CPU
and samples the time they spend in stall states. Every 2 seconds, the
samples are averaged across CPUs - weighted by the CPUs' non-idle time to
eliminate artifacts from unused CPUs - and translated into percentages of
walltime. A running average of those percentages is maintained over 10s,
1m, and 5m periods (similar to the loadaverage).
[hannes@cmpxchg.org: doc fixlet, per Randy]
Link: http://lkml.kernel.org/r/20180828205625.GA14030@cmpxchg.org
[hannes@cmpxchg.org: code optimization]
Link: http://lkml.kernel.org/r/20180907175015.GA8479@cmpxchg.org
[hannes@cmpxchg.org: rename psi_clock() to psi_update_work(), per Peter]
Link: http://lkml.kernel.org/r/20180907145404.GB11088@cmpxchg.org
[hannes@cmpxchg.org: fix build]
Link: http://lkml.kernel.org/r/20180913014222.GA2370@cmpxchg.org
Link: http://lkml.kernel.org/r/20180828172258.3185-9-hannes@cmpxchg.org
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Daniel Drake <drake@endlessm.com>
Tested-by: Suren Baghdasaryan <surenb@google.com>
Cc: Christopher Lameter <cl@linux.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Johannes Weiner <jweiner@fb.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Enderborg <peter.enderborg@sony.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Vinayak Menon <vinmenon@codeaurora.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-10-26 22:06:27 +00:00
|
|
|
|
|
|
|
The "some" line indicates the share of time in which at least some
|
|
|
|
tasks are stalled on a given resource.
|
|
|
|
|
|
|
|
The "full" line indicates the share of time in which all non-idle
|
|
|
|
tasks are stalled on a given resource simultaneously. In this state
|
|
|
|
actual CPU cycles are going to waste, and a workload that spends
|
|
|
|
extended time in this state is considered to be thrashing. This has
|
|
|
|
severe impact on performance, and it's useful to distinguish this
|
|
|
|
situation from a state where some tasks are stalled but the CPU is
|
|
|
|
still doing productive work. As such, time spent in this subset of the
|
|
|
|
stall state is tracked separately and exported in the "full" averages.
|
|
|
|
|
2022-04-08 12:19:14 +00:00
|
|
|
CPU full is undefined at the system level, but has been reported
|
|
|
|
since 5.13, so it is set to zero for backward compatibility.
|
|
|
|
|
2019-04-06 01:39:14 +00:00
|
|
|
The ratios (in %) are tracked as recent trends over ten, sixty, and
|
|
|
|
three hundred second windows, which gives insight into short term events
|
|
|
|
as well as medium and long term trends. The total absolute stall time
|
|
|
|
(in us) is tracked and exported as well, to allow detection of latency
|
|
|
|
spikes which wouldn't necessarily make a dent in the time averages,
|
|
|
|
or to average trends over custom time frames.
|
2018-10-26 22:06:31 +00:00
|
|
|
|
2019-05-14 22:41:15 +00:00
|
|
|
Monitoring for pressure thresholds
|
|
|
|
==================================
|
|
|
|
|
|
|
|
Users can register triggers and use poll() to be woken up when resource
|
|
|
|
pressure exceeds certain thresholds.
|
|
|
|
|
|
|
|
A trigger describes the maximum cumulative stall time over a specific
|
|
|
|
time window, e.g. 100ms of total stall time within any 500ms window to
|
|
|
|
generate a wakeup event.
|
|
|
|
|
|
|
|
To register a trigger user has to open psi interface file under
|
|
|
|
/proc/pressure/ representing the resource to be monitored and write the
|
|
|
|
desired threshold and time window. The open file descriptor should be
|
|
|
|
used to wait for trigger events using select(), poll() or epoll().
|
2019-04-17 08:46:08 +00:00
|
|
|
The following format is used::
|
2019-05-14 22:41:15 +00:00
|
|
|
|
2019-04-17 08:46:08 +00:00
|
|
|
<some|full> <stall amount in us> <time window in us>
|
2019-05-14 22:41:15 +00:00
|
|
|
|
|
|
|
For example writing "some 150000 1000000" into /proc/pressure/memory
|
|
|
|
would add 150ms threshold for partial memory stall measured within
|
|
|
|
1sec time window. Writing "full 50000 1000000" into /proc/pressure/io
|
|
|
|
would add 50ms threshold for full io stall measured within 1sec time window.
|
|
|
|
|
|
|
|
Triggers can be set on more than one psi metric and more than one trigger
|
|
|
|
for the same psi metric can be specified. However for each trigger a separate
|
|
|
|
file descriptor is required to be able to poll it separately from others,
|
|
|
|
therefore for each trigger a separate open() syscall should be made even
|
2022-01-11 23:23:09 +00:00
|
|
|
when opening the same psi interface file. Write operations to a file descriptor
|
|
|
|
with an already existing psi trigger will fail with EBUSY.
|
2019-05-14 22:41:15 +00:00
|
|
|
|
|
|
|
Monitors activate only when system enters stall state for the monitored
|
|
|
|
psi metric and deactivates upon exit from the stall state. While system is
|
|
|
|
in the stall state psi signal growth is monitored at a rate of 10 times per
|
|
|
|
tracking window.
|
|
|
|
|
|
|
|
The kernel accepts window sizes ranging from 500ms to 10s, therefore min
|
|
|
|
monitoring update interval is 50ms and max is 1s. Min limit is set to
|
|
|
|
prevent overly frequent polling. Max limit is chosen as a high enough number
|
|
|
|
after which monitors are most likely not needed and psi averages can be used
|
|
|
|
instead.
|
|
|
|
|
2023-03-30 10:54:18 +00:00
|
|
|
Unprivileged users can also create monitors, with the only limitation that the
|
|
|
|
window size must be a multiple of 2s, in order to prevent excessive resource
|
|
|
|
usage.
|
|
|
|
|
2019-05-14 22:41:15 +00:00
|
|
|
When activated, psi monitor stays active for at least the duration of one
|
|
|
|
tracking window to avoid repeated activations/deactivations when system is
|
|
|
|
bouncing in and out of the stall state.
|
|
|
|
|
|
|
|
Notifications to the userspace are rate-limited to one per tracking window.
|
|
|
|
|
|
|
|
The trigger will de-register when the file descriptor used to define the
|
|
|
|
trigger is closed.
|
|
|
|
|
|
|
|
Userspace monitor usage example
|
|
|
|
===============================
|
|
|
|
|
2019-04-17 08:46:08 +00:00
|
|
|
::
|
|
|
|
|
|
|
|
#include <errno.h>
|
|
|
|
#include <fcntl.h>
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <poll.h>
|
|
|
|
#include <string.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Monitor memory partial stall with 1s tracking window size
|
|
|
|
* and 150ms threshold.
|
|
|
|
*/
|
|
|
|
int main() {
|
2019-05-14 22:41:15 +00:00
|
|
|
const char trig[] = "some 150000 1000000";
|
|
|
|
struct pollfd fds;
|
|
|
|
int n;
|
|
|
|
|
|
|
|
fds.fd = open("/proc/pressure/memory", O_RDWR | O_NONBLOCK);
|
|
|
|
if (fds.fd < 0) {
|
|
|
|
printf("/proc/pressure/memory open error: %s\n",
|
|
|
|
strerror(errno));
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
fds.events = POLLPRI;
|
|
|
|
|
|
|
|
if (write(fds.fd, trig, strlen(trig) + 1) < 0) {
|
|
|
|
printf("/proc/pressure/memory write error: %s\n",
|
|
|
|
strerror(errno));
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
printf("waiting for events...\n");
|
|
|
|
while (1) {
|
|
|
|
n = poll(&fds, 1, -1);
|
|
|
|
if (n < 0) {
|
|
|
|
printf("poll error: %s\n", strerror(errno));
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
if (fds.revents & POLLERR) {
|
|
|
|
printf("got POLLERR, event source is gone\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (fds.revents & POLLPRI) {
|
|
|
|
printf("event triggered!\n");
|
|
|
|
} else {
|
|
|
|
printf("unknown event received: 0x%x\n", fds.revents);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
2019-04-17 08:46:08 +00:00
|
|
|
}
|
2019-05-14 22:41:15 +00:00
|
|
|
|
2018-10-26 22:06:31 +00:00
|
|
|
Cgroup2 interface
|
|
|
|
=================
|
|
|
|
|
|
|
|
In a system with a CONFIG_CGROUP=y kernel and the cgroup2 filesystem
|
|
|
|
mounted, pressure stall information is also tracked for tasks grouped
|
|
|
|
into cgroups. Each subdirectory in the cgroupfs mountpoint contains
|
|
|
|
cpu.pressure, memory.pressure, and io.pressure files; the format is
|
|
|
|
the same as the /proc/pressure/ files.
|
2019-05-14 22:41:15 +00:00
|
|
|
|
|
|
|
Per-cgroup psi monitors can be specified and used the same way as
|
|
|
|
system-wide ones.
|