proc.5, proc_pid_io.5: Split /proc/PID/io from proc(5)

Signed-off-by: Alejandro Colomar <alx@kernel.org>

diff --git a/man5/proc.5 b/man5/proc.5
index d3b762c74f67f493aed0d431c7a95d82c3142b2d..c931cea645ea748a29edb69f8c733ed797f48af3 100644 (file)
--- a/man5/proc.5
+++ b/man5/proc.5
@@ -267,92 +267,6 @@ Therefore, it may be desirable to reset the "dumpable" attribute
 .I after
 making any desired changes to the process's effective UID or GID.
 .TP
-.IR /proc/ pid /io " (since Linux 2.6.20)"
-.\" commit 7c3ab7381e79dfc7db14a67c6f4f3285664e1ec2
-This file contains I/O statistics for the process, for example:
-.IP
-.in +4n
-.EX
-.RB "#" " cat /proc/3828/io"
-rchar: 323934931
-wchar: 323929600
-syscr: 632687
-syscw: 632675
-read_bytes: 0
-write_bytes: 323932160
-cancelled_write_bytes: 0
-.EE
-.in
-.IP
-The fields are as follows:
-.RS
-.TP
-.IR rchar ": characters read"
-The number of bytes which this task has caused to be read from storage.
-This is simply the sum of bytes which this process passed to
-.BR read (2)
-and similar system calls.
-It includes things such as terminal I/O and
-is unaffected by whether or not actual
-physical disk I/O was required (the read might have been satisfied from
-pagecache).
-.TP
-.IR wchar ": characters written"
-The number of bytes which this task has caused, or shall cause to be written
-to disk.
-Similar caveats apply here as with
-.IR rchar .
-.TP
-.IR syscr ": read syscalls"
-Attempt to count the number of read I/O operations\[em]that is,
-system calls such as
-.BR read (2)
-and
-.BR pread (2).
-.TP
-.IR syscw ": write syscalls"
-Attempt to count the number of write I/O operations\[em]that is,
-system calls such as
-.BR write (2)
-and
-.BR pwrite (2).
-.TP
-.IR read_bytes ": bytes read"
-Attempt to count the number of bytes which this process really did cause to
-be fetched from the storage layer.
-This is accurate for block-backed filesystems.
-.TP
-.IR write_bytes ": bytes written"
-Attempt to count the number of bytes which this process caused to be sent to
-the storage layer.
-.TP
-.IR cancelled_write_bytes :
-The big inaccuracy here is truncate.
-If a process writes 1 MB to a file and then deletes the file,
-it will in fact perform no writeout.
-But it will have been accounted as having caused 1 MB of write.
-In other words: this field represents the number of bytes which this process
-caused to not happen, by truncating pagecache.
-A task can cause "negative" I/O too.
-If this task truncates some dirty pagecache,
-some I/O which another task has been accounted for
-(in its
-.IR write_bytes )
-will not be happening.
-.RE
-.IP
-.IR Note :
-In the current implementation, things are a bit racy on 32-bit systems:
-if process A reads process B's
-.IR /proc/ pid /io
-while process B is updating one of these 64-bit counters,
-process A could see an intermediate result.
-.IP
-Permission to access this file is governed by a ptrace access mode
-.B PTRACE_MODE_READ_FSCREDS
-check; see
-.BR ptrace (2).
-.TP
 .IR /proc/ pid /limits " (since Linux 2.6.24)"
 This file displays the soft limit, hard limit, and units of measurement
 for each of the process's resource limits (see

diff --git a/man5/proc_pid_io.5 b/man5/proc_pid_io.5
new file mode 100644 (file)
index 0000000..1242523
--- /dev/null
+++ b/man5/proc_pid_io.5
@@ -0,0 +1,98 @@
+.\" Copyright (C) 1994, 1995, Daniel Quinlan <quinlan@yggdrasil.com>
+.\" Copyright (C) 2002-2008, 2017, Michael Kerrisk <mtk.manpages@gmail.com>
+.\" Copyright (C) 2023, Alejandro Colomar <alx@kernel.org>
+.\"
+.\" SPDX-License-Identifier: GPL-3.0-or-later
+.\"
+.TH proc_pid_io 5 (date) "Linux man-pages (unreleased)"
+.SH NAME
+/proc/pid/io \- I/O statistics
+.SH DESCRIPTION
+.TP
+.IR /proc/ pid /io " (since Linux 2.6.20)"
+.\" commit 7c3ab7381e79dfc7db14a67c6f4f3285664e1ec2
+This file contains I/O statistics for the process, for example:
+.IP
+.in +4n
+.EX
+.RB "#" " cat /proc/3828/io"
+rchar: 323934931
+wchar: 323929600
+syscr: 632687
+syscw: 632675
+read_bytes: 0
+write_bytes: 323932160
+cancelled_write_bytes: 0
+.EE
+.in
+.IP
+The fields are as follows:
+.RS
+.TP
+.IR rchar ": characters read"
+The number of bytes which this task has caused to be read from storage.
+This is simply the sum of bytes which this process passed to
+.BR read (2)
+and similar system calls.
+It includes things such as terminal I/O and
+is unaffected by whether or not actual
+physical disk I/O was required (the read might have been satisfied from
+pagecache).
+.TP
+.IR wchar ": characters written"
+The number of bytes which this task has caused, or shall cause to be written
+to disk.
+Similar caveats apply here as with
+.IR rchar .
+.TP
+.IR syscr ": read syscalls"
+Attempt to count the number of read I/O operations\[em]that is,
+system calls such as
+.BR read (2)
+and
+.BR pread (2).
+.TP
+.IR syscw ": write syscalls"
+Attempt to count the number of write I/O operations\[em]that is,
+system calls such as
+.BR write (2)
+and
+.BR pwrite (2).
+.TP
+.IR read_bytes ": bytes read"
+Attempt to count the number of bytes which this process really did cause to
+be fetched from the storage layer.
+This is accurate for block-backed filesystems.
+.TP
+.IR write_bytes ": bytes written"
+Attempt to count the number of bytes which this process caused to be sent to
+the storage layer.
+.TP
+.IR cancelled_write_bytes :
+The big inaccuracy here is truncate.
+If a process writes 1 MB to a file and then deletes the file,
+it will in fact perform no writeout.
+But it will have been accounted as having caused 1 MB of write.
+In other words: this field represents the number of bytes which this process
+caused to not happen, by truncating pagecache.
+A task can cause "negative" I/O too.
+If this task truncates some dirty pagecache,
+some I/O which another task has been accounted for
+(in its
+.IR write_bytes )
+will not be happening.
+.RE
+.IP
+.IR Note :
+In the current implementation, things are a bit racy on 32-bit systems:
+if process A reads process B's
+.IR /proc/ pid /io
+while process B is updating one of these 64-bit counters,
+process A could see an intermediate result.
+.IP
+Permission to access this file is governed by a ptrace access mode
+.B PTRACE_MODE_READ_FSCREDS
+check; see
+.BR ptrace (2).
+.SH SEE ALSO
+.BR proc (5)