Let's make wrap-around documented behavior so that userspace has no excuses for not handling it properly if they want accurate values. On 32-bit platforms "intr" and "softirq" counters can and will wrap-around, given enough time since boot. This can be days or hours, depending on the load. On 64-bit platforms these counters use 64-bit values and these are very unlikely to oveflow before the heat death of the universe, but it's still technically possible. Many other counters can wrap-arond too but I'm not going to enumerate all of them here. The interrupt counters are most likely to overflow. Signed-off-by: Alexei Lozovsky <me@xxxxxxxxxx> --- Documentation/filesystems/proc.rst | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 042c418f4090..a33af0074838 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -1513,6 +1513,14 @@ interrupts serviced including unnumbered architecture specific interrupts; each subsequent column is the total for that particular numbered interrupt. Unnumbered interrupts are not shown, only summed into the total. +.. note:: + + On 32-bit platforms interrupt counters are 32-bit, including the total + count of all interrupts. Depending on the system load, these values will + sooner or later wrap around. If you want accurate accounting of the rate + and *actual* number of interrupts serviced, you should monitor the value + closely and handle wrap-arounds. + The "ctxt" line gives the total number of context switches across all CPUs. The "btime" line gives the time at which the system booted, in seconds since -- 2.25.1
