* [PATCH 2/6] proc_pid_io.5: dewafflify
2024-03-13 14:26 [PATCH 1/6] proc_pid_io.5: stats include children наб
@ 2024-03-13 14:26 ` наб
2024-03-14 16:21 ` Alejandro Colomar
2024-03-13 14:26 ` [PATCH 3/6] proc_pid_io.5: wfix наб
` (6 subsequent siblings)
7 siblings, 1 reply; 20+ messages in thread
From: наб @ 2024-03-13 14:26 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: linux-man
[-- Attachment #1: Type: text/plain, Size: 4773 bytes --]
This page copies verbatim the contents of
Documentation/filesystems/proc.rst, added wholesale in
commit f9c99463b0cd05603d125c915e2886d55a686b82 ("[PATCH] Documentation
for io-accounting / reporting via procfs") in 2007.
As such, it mirrors the sensibilities of the time ‒
writing "successful read returns" as "data pulled from storage. actually
just the data the process gave to read(). this also means from non-regular
files! whether the data was pulled from storage doesn't matter actually
(obligatory cache mention)"
for the modern reader this is just a lot of waffling
(note also that processes give no data to read()!)
‒ and sensibilities of the sheepish implementer in kernel documentation ‒
"an attempt" for a well-defined kernel behaviour, mentioning the
"current implementation", consistent mentions of specific kernel-internal
caching mechanisms, "the big inaccuracy here".
Re-write to be more useful and less misleading as documentation;
the syscall enumeration is accurate for kernel v6.8, but the sysc? stats
are also bumped by kernel_{read,write}(), which is sometimes used by too
many syscalls in too many scenarios to usefully enumerate.
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
man5/proc_pid_io.5 | 62 ++++++++++++++++++++++------------------------
1 file changed, 30 insertions(+), 32 deletions(-)
diff --git a/man5/proc_pid_io.5 b/man5/proc_pid_io.5
index 81cfdd249..f66d8c635 100644
--- a/man5/proc_pid_io.5
+++ b/man5/proc_pid_io.5
@@ -30,57 +30,55 @@ .SH DESCRIPTION
.RS
.TP
.IR rchar ": characters read"
-The number of bytes which this task and its waited-for children have caused to be read from storage.
-This is simply the sum of bytes which this process passed to
+The number of bytes returned by successful
.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 and its waited-for children has caused, or shall cause to be written
-to disk.
-Similar caveats apply here as with
-.IR rchar .
+The number of bytes returned by successful
+.BR write (2)
+and similar system calls.
.TP
.IR syscr ": read syscalls"
-Attempt to count the number of read I/O operations\[em]that is,
-system calls such as
+The number of "I/O read" system calls\[em]those from the
.BR read (2)
+family
+(including when invoked used by the kernel as part of other syscalls),
+.BR sendfile (2),
+.BR copy_file_range (2),
and
-.BR pread (2).
+.BR ioctl (2)
+.BR BTRFS_IOC_ENCODED_READ [ _32 ].
.TP
.IR syscw ": write syscalls"
-Attempt to count the number of write I/O operations\[em]that is,
-system calls such as
+The number of "I/O write" system calls\[em]those from the
.BR write (2)
+family
+(including when invoked used by the kernel as part of other syscalls),
+.BR sendfile (2),
+.BR copy_file_range (2),
and
-.BR pwrite (2).
+.BR ioctl (2)
+.BR BTRFS_IOC_ENCODED_WRITE [ _32 ].
.TP
.IR read_bytes ": bytes read"
-Attempt to count the number of bytes which this process and its waited-for children really did cause to
-be fetched from the storage layer.
+The number of bytes really 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 and its waited-for children caused to be sent to
-the storage layer.
+The number of bytes really 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 and its waited-for children
-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.
+The above statistics fail to account for truncation:
+if a process writes 1 MB to a regular file and then removes it,
+said 1 MB will not be written, but
+.I will
+have nevertheless been accounted as a 1 MB write.
+This field represents the number of bytes "saved" from I/O writeback.
+This can yield to having done negative I/O
+if caches dirtied by another process are truncated.
+This figure applies to I/O already accounted-for by
+.IR write_bytes .
.RE
.IP
.IR Note :
--
2.39.2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH 2/6] proc_pid_io.5: dewafflify
2024-03-13 14:26 ` [PATCH 2/6] proc_pid_io.5: dewafflify наб
@ 2024-03-14 16:21 ` Alejandro Colomar
0 siblings, 0 replies; 20+ messages in thread
From: Alejandro Colomar @ 2024-03-14 16:21 UTC (permalink / raw)
To: наб; +Cc: linux-man
[-- Attachment #1: Type: text/plain, Size: 5199 bytes --]
On Wed, Mar 13, 2024 at 03:26:46PM +0100, наб wrote:
> This page copies verbatim the contents of
> Documentation/filesystems/proc.rst, added wholesale in
> commit f9c99463b0cd05603d125c915e2886d55a686b82 ("[PATCH] Documentation
> for io-accounting / reporting via procfs") in 2007.
>
> As such, it mirrors the sensibilities of the time ‒
> writing "successful read returns" as "data pulled from storage. actually
> just the data the process gave to read(). this also means from non-regular
> files! whether the data was pulled from storage doesn't matter actually
> (obligatory cache mention)"
> for the modern reader this is just a lot of waffling
> (note also that processes give no data to read()!)
> ‒ and sensibilities of the sheepish implementer in kernel documentation ‒
> "an attempt" for a well-defined kernel behaviour, mentioning the
> "current implementation", consistent mentions of specific kernel-internal
> caching mechanisms, "the big inaccuracy here".
>
> Re-write to be more useful and less misleading as documentation;
> the syscall enumeration is accurate for kernel v6.8, but the sysc? stats
> are also bumped by kernel_{read,write}(), which is sometimes used by too
> many syscalls in too many scenarios to usefully enumerate.
>
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Depends on patch 1. Please rebase after you change 1.
Thanks,
Alex
> ---
> man5/proc_pid_io.5 | 62 ++++++++++++++++++++++------------------------
> 1 file changed, 30 insertions(+), 32 deletions(-)
>
> diff --git a/man5/proc_pid_io.5 b/man5/proc_pid_io.5
> index 81cfdd249..f66d8c635 100644
> --- a/man5/proc_pid_io.5
> +++ b/man5/proc_pid_io.5
> @@ -30,57 +30,55 @@ .SH DESCRIPTION
> .RS
> .TP
> .IR rchar ": characters read"
> -The number of bytes which this task and its waited-for children have caused to be read from storage.
> -This is simply the sum of bytes which this process passed to
> +The number of bytes returned by successful
> .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 and its waited-for children has caused, or shall cause to be written
> -to disk.
> -Similar caveats apply here as with
> -.IR rchar .
> +The number of bytes returned by successful
> +.BR write (2)
> +and similar system calls.
> .TP
> .IR syscr ": read syscalls"
> -Attempt to count the number of read I/O operations\[em]that is,
> -system calls such as
> +The number of "I/O read" system calls\[em]those from the
> .BR read (2)
> +family
> +(including when invoked used by the kernel as part of other syscalls),
> +.BR sendfile (2),
> +.BR copy_file_range (2),
> and
> -.BR pread (2).
> +.BR ioctl (2)
> +.BR BTRFS_IOC_ENCODED_READ [ _32 ].
> .TP
> .IR syscw ": write syscalls"
> -Attempt to count the number of write I/O operations\[em]that is,
> -system calls such as
> +The number of "I/O write" system calls\[em]those from the
> .BR write (2)
> +family
> +(including when invoked used by the kernel as part of other syscalls),
> +.BR sendfile (2),
> +.BR copy_file_range (2),
> and
> -.BR pwrite (2).
> +.BR ioctl (2)
> +.BR BTRFS_IOC_ENCODED_WRITE [ _32 ].
> .TP
> .IR read_bytes ": bytes read"
> -Attempt to count the number of bytes which this process and its waited-for children really did cause to
> -be fetched from the storage layer.
> +The number of bytes really 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 and its waited-for children caused to be sent to
> -the storage layer.
> +The number of bytes really 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 and its waited-for children
> -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.
> +The above statistics fail to account for truncation:
> +if a process writes 1 MB to a regular file and then removes it,
> +said 1 MB will not be written, but
> +.I will
> +have nevertheless been accounted as a 1 MB write.
> +This field represents the number of bytes "saved" from I/O writeback.
> +This can yield to having done negative I/O
> +if caches dirtied by another process are truncated.
> +This figure applies to I/O already accounted-for by
> +.IR write_bytes .
> .RE
> .IP
> .IR Note :
> --
> 2.39.2
>
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 3/6] proc_pid_io.5: wfix
2024-03-13 14:26 [PATCH 1/6] proc_pid_io.5: stats include children наб
2024-03-13 14:26 ` [PATCH 2/6] proc_pid_io.5: dewafflify наб
@ 2024-03-13 14:26 ` наб
2024-03-14 16:22 ` Alejandro Colomar
2024-03-13 14:26 ` [PATCH 4/6] proc_pid_io.5: mention atomicity in atomicity note наб
` (5 subsequent siblings)
7 siblings, 1 reply; 20+ messages in thread
From: наб @ 2024-03-13 14:26 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: linux-man
[-- Attachment #1: Type: text/plain, Size: 739 bytes --]
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
man5/proc_pid_io.5 | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/man5/proc_pid_io.5 b/man5/proc_pid_io.5
index f66d8c635..4d97bd95f 100644
--- a/man5/proc_pid_io.5
+++ b/man5/proc_pid_io.5
@@ -88,9 +88,9 @@ .SH DESCRIPTION
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).
+Permission to access this file is governed by
+.BR ptrace (2)
+access mode
+.BR PTRACE_MODE_READ_FSCREDS .
.SH SEE ALSO
.BR proc (5)
--
2.39.2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH 3/6] proc_pid_io.5: wfix
2024-03-13 14:26 ` [PATCH 3/6] proc_pid_io.5: wfix наб
@ 2024-03-14 16:22 ` Alejandro Colomar
0 siblings, 0 replies; 20+ messages in thread
From: Alejandro Colomar @ 2024-03-14 16:22 UTC (permalink / raw)
To: наб; +Cc: linux-man
[-- Attachment #1: Type: text/plain, Size: 942 bytes --]
On Wed, Mar 13, 2024 at 03:26:48PM +0100, наб wrote:
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Patch applied. Thanks.
Cheers,
Alex
> ---
> man5/proc_pid_io.5 | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/man5/proc_pid_io.5 b/man5/proc_pid_io.5
> index f66d8c635..4d97bd95f 100644
> --- a/man5/proc_pid_io.5
> +++ b/man5/proc_pid_io.5
> @@ -88,9 +88,9 @@ .SH DESCRIPTION
> 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).
> +Permission to access this file is governed by
> +.BR ptrace (2)
> +access mode
> +.BR PTRACE_MODE_READ_FSCREDS .
> .SH SEE ALSO
> .BR proc (5)
> --
> 2.39.2
>
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 4/6] proc_pid_io.5: mention atomicity in atomicity note
2024-03-13 14:26 [PATCH 1/6] proc_pid_io.5: stats include children наб
2024-03-13 14:26 ` [PATCH 2/6] proc_pid_io.5: dewafflify наб
2024-03-13 14:26 ` [PATCH 3/6] proc_pid_io.5: wfix наб
@ 2024-03-13 14:26 ` наб
2024-03-14 16:28 ` Alejandro Colomar
2024-03-13 14:26 ` [PATCH 5/6] getrusage.2: proc(5) /proc/pid/stat -> proc_pid_stat(5) наб
` (4 subsequent siblings)
7 siblings, 1 reply; 20+ messages in thread
From: наб @ 2024-03-13 14:26 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: linux-man
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]
And drop "current implementation"
(wording still literal from Documentation/filesystems/proc.rst).
Of course this describes the current implementation.
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
man5/proc_pid_io.5 | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/man5/proc_pid_io.5 b/man5/proc_pid_io.5
index 4d97bd95f..181717192 100644
--- a/man5/proc_pid_io.5
+++ b/man5/proc_pid_io.5
@@ -82,11 +82,10 @@ .SH DESCRIPTION
.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.
+these counters are not atomic:
+on systems where 64-bit integer operations may tear,
+a counter could be updated simultaneously with a read,
+yielding an incorrect intermediate value.
.IP
Permission to access this file is governed by
.BR ptrace (2)
--
2.39.2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH 4/6] proc_pid_io.5: mention atomicity in atomicity note
2024-03-13 14:26 ` [PATCH 4/6] proc_pid_io.5: mention atomicity in atomicity note наб
@ 2024-03-14 16:28 ` Alejandro Colomar
0 siblings, 0 replies; 20+ messages in thread
From: Alejandro Colomar @ 2024-03-14 16:28 UTC (permalink / raw)
To: наб; +Cc: linux-man
[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]
Hi,
> Subject: Re: [PATCH 4/6] proc_pid_io.5: mention atomicity in atomicity note
Please use uppercase after the prefix. That is:
proc_pid_io.5: Mention atomicity in atomicity note
At least to me, it seems to help see where the sentence starts. Maybe
you can convince me of the opposite, though, if you try.
On Wed, Mar 13, 2024 at 03:26:50PM +0100, наб wrote:
> And drop "current implementation"
> (wording still literal from Documentation/filesystems/proc.rst).
> Of course this describes the current implementation.
>
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> ---
> man5/proc_pid_io.5 | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/man5/proc_pid_io.5 b/man5/proc_pid_io.5
> index 4d97bd95f..181717192 100644
> --- a/man5/proc_pid_io.5
> +++ b/man5/proc_pid_io.5
> @@ -82,11 +82,10 @@ .SH DESCRIPTION
> .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.
> +these counters are not atomic:
> +on systems where 64-bit integer operations may tear,
> +a counter could be updated simultaneously with a read,
> +yielding an incorrect intermediate value.
Hmmm, I think this should be a CAVEATS section. Since you'll have to
send more patches for this page, would you mind adding one that moves
this paragraph to a CAVEATS section?
Anyway, I've applied this patch. Thanks!
Cheers,
Alex
> .IP
> Permission to access this file is governed by
> .BR ptrace (2)
> --
> 2.39.2
>
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 5/6] getrusage.2: proc(5) /proc/pid/stat -> proc_pid_stat(5)
2024-03-13 14:26 [PATCH 1/6] proc_pid_io.5: stats include children наб
` (2 preceding siblings ...)
2024-03-13 14:26 ` [PATCH 4/6] proc_pid_io.5: mention atomicity in atomicity note наб
@ 2024-03-13 14:26 ` наб
2024-03-14 16:31 ` Alejandro Colomar
2024-03-13 14:26 ` [PATCH 6/6] getrusage.2, proc_pid_io.5: crosslink наб
` (3 subsequent siblings)
7 siblings, 1 reply; 20+ messages in thread
From: наб @ 2024-03-13 14:26 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: linux-man
[-- Attachment #1: Type: text/plain, Size: 671 bytes --]
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
man2/getrusage.2 | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/man2/getrusage.2 b/man2/getrusage.2
index 8323bef35..8baff09c4 100644
--- a/man2/getrusage.2
+++ b/man2/getrusage.2
@@ -239,15 +239,11 @@ .SH HISTORY
.SH NOTES
Resource usage metrics are preserved across an
.BR execve (2).
-.P
-See also the description of
-.IR /proc/ pid /stat
-in
-.BR proc (5).
.SH SEE ALSO
.BR clock_gettime (2),
.BR getrlimit (2),
.BR times (2),
.BR wait (2),
.BR wait4 (2),
-.BR clock (3)
+.BR clock (3),
+.BR proc_pid_stat (5)
--
2.39.2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH 5/6] getrusage.2: proc(5) /proc/pid/stat -> proc_pid_stat(5)
2024-03-13 14:26 ` [PATCH 5/6] getrusage.2: proc(5) /proc/pid/stat -> proc_pid_stat(5) наб
@ 2024-03-14 16:31 ` Alejandro Colomar
0 siblings, 0 replies; 20+ messages in thread
From: Alejandro Colomar @ 2024-03-14 16:31 UTC (permalink / raw)
To: наб; +Cc: linux-man
[-- Attachment #1: Type: text/plain, Size: 996 bytes --]
Hi!
On Wed, Mar 13, 2024 at 03:26:52PM +0100, наб wrote:
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
I've also added
Fixes: bbc21bc4dbef ("proc.5, proc_pid_stat.5: Split /proc/PID/stat from proc(5)")
Patch applied. Thanks!
Cheers,
Alex
> ---
> man2/getrusage.2 | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/man2/getrusage.2 b/man2/getrusage.2
> index 8323bef35..8baff09c4 100644
> --- a/man2/getrusage.2
> +++ b/man2/getrusage.2
> @@ -239,15 +239,11 @@ .SH HISTORY
> .SH NOTES
> Resource usage metrics are preserved across an
> .BR execve (2).
> -.P
> -See also the description of
> -.IR /proc/ pid /stat
> -in
> -.BR proc (5).
> .SH SEE ALSO
> .BR clock_gettime (2),
> .BR getrlimit (2),
> .BR times (2),
> .BR wait (2),
> .BR wait4 (2),
> -.BR clock (3)
> +.BR clock (3),
> +.BR proc_pid_stat (5)
> --
> 2.39.2
>
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 6/6] getrusage.2, proc_pid_io.5: crosslink
2024-03-13 14:26 [PATCH 1/6] proc_pid_io.5: stats include children наб
` (3 preceding siblings ...)
2024-03-13 14:26 ` [PATCH 5/6] getrusage.2: proc(5) /proc/pid/stat -> proc_pid_stat(5) наб
@ 2024-03-13 14:26 ` наб
2024-03-14 16:33 ` Alejandro Colomar
2024-03-14 16:19 ` [PATCH 1/6] proc_pid_io.5: stats include children Alejandro Colomar
` (2 subsequent siblings)
7 siblings, 1 reply; 20+ messages in thread
From: наб @ 2024-03-13 14:26 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: linux-man
[-- Attachment #1: Type: text/plain, Size: 821 bytes --]
These serve the same purpose from different perspectives
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
man2/getrusage.2 | 3 ++-
man5/proc_pid_io.5 | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/man2/getrusage.2 b/man2/getrusage.2
index 8baff09c4..2ae9dafa4 100644
--- a/man2/getrusage.2
+++ b/man2/getrusage.2
@@ -246,4 +246,5 @@ .SH SEE ALSO
.BR wait (2),
.BR wait4 (2),
.BR clock (3),
-.BR proc_pid_stat (5)
+.BR proc_pid_stat (5),
+.BR proc_pid_io (5)
diff --git a/man5/proc_pid_io.5 b/man5/proc_pid_io.5
index 181717192..d0116ba13 100644
--- a/man5/proc_pid_io.5
+++ b/man5/proc_pid_io.5
@@ -92,4 +92,5 @@ .SH DESCRIPTION
access mode
.BR PTRACE_MODE_READ_FSCREDS .
.SH SEE ALSO
+.BR getrusage (2),
.BR proc (5)
--
2.39.2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH 6/6] getrusage.2, proc_pid_io.5: crosslink
2024-03-13 14:26 ` [PATCH 6/6] getrusage.2, proc_pid_io.5: crosslink наб
@ 2024-03-14 16:33 ` Alejandro Colomar
0 siblings, 0 replies; 20+ messages in thread
From: Alejandro Colomar @ 2024-03-14 16:33 UTC (permalink / raw)
To: наб; +Cc: linux-man
[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]
On Wed, Mar 13, 2024 at 03:26:54PM +0100, наб wrote:
> These serve the same purpose from different perspectives
>
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Thanks! Patch applied.
Have a lovely day!
Alex
> ---
> man2/getrusage.2 | 3 ++-
> man5/proc_pid_io.5 | 1 +
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/man2/getrusage.2 b/man2/getrusage.2
> index 8baff09c4..2ae9dafa4 100644
> --- a/man2/getrusage.2
> +++ b/man2/getrusage.2
> @@ -246,4 +246,5 @@ .SH SEE ALSO
> .BR wait (2),
> .BR wait4 (2),
> .BR clock (3),
> -.BR proc_pid_stat (5)
> +.BR proc_pid_stat (5),
> +.BR proc_pid_io (5)
> diff --git a/man5/proc_pid_io.5 b/man5/proc_pid_io.5
> index 181717192..d0116ba13 100644
> --- a/man5/proc_pid_io.5
> +++ b/man5/proc_pid_io.5
> @@ -92,4 +92,5 @@ .SH DESCRIPTION
> access mode
> .BR PTRACE_MODE_READ_FSCREDS .
> .SH SEE ALSO
> +.BR getrusage (2),
> .BR proc (5)
> --
> 2.39.2
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/6] proc_pid_io.5: stats include children
2024-03-13 14:26 [PATCH 1/6] proc_pid_io.5: stats include children наб
` (4 preceding siblings ...)
2024-03-13 14:26 ` [PATCH 6/6] getrusage.2, proc_pid_io.5: crosslink наб
@ 2024-03-14 16:19 ` Alejandro Colomar
2024-03-17 11:01 ` [PATCH v2 2/2] proc_pid_io.5: dewafflify наб
2024-03-17 11:01 ` [PATCH v2 1/2] proc_pid_io.5: stats include children наб
7 siblings, 0 replies; 20+ messages in thread
From: Alejandro Colomar @ 2024-03-14 16:19 UTC (permalink / raw)
To: наб; +Cc: linux-man
[-- Attachment #1: Type: text/plain, Size: 3086 bytes --]
Hi наб,
On Wed, Mar 13, 2024 at 03:26:44PM +0100, наб wrote:
> This file is like getrusage(2) RUSAGE_SELF + RUSAGE_CHILDREN,
> the current wording implies it's like just RUSAGE_SELF.
>
> Compare:
[...]
LGTM.
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> ---
> man5/proc_pid_io.5 | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/man5/proc_pid_io.5 b/man5/proc_pid_io.5
> index 124252319..81cfdd249 100644
> --- a/man5/proc_pid_io.5
> +++ b/man5/proc_pid_io.5
> @@ -11,7 +11,7 @@ .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:
> +This file contains I/O statistics for the process and its waited-for children, for example:
Please use semantic newlines. Maybe after 'statistics'? And then also
after the comma. Do a similar thing in the hunks below.
Have a lovely day!
Alex
> .IP
> .in +4n
> .EX
> @@ -30,7 +30,7 @@ .SH DESCRIPTION
> .RS
> .TP
> .IR rchar ": characters read"
> -The number of bytes which this task has caused to be read from storage.
> +The number of bytes which this task and its waited-for children have 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.
> @@ -40,7 +40,7 @@ .SH DESCRIPTION
> pagecache).
> .TP
> .IR wchar ": characters written"
> -The number of bytes which this task has caused, or shall cause to be written
> +The number of bytes which this task and its waited-for children has caused, or shall cause to be written
> to disk.
> Similar caveats apply here as with
> .IR rchar .
> @@ -60,12 +60,12 @@ .SH DESCRIPTION
> .BR pwrite (2).
> .TP
> .IR read_bytes ": bytes read"
> -Attempt to count the number of bytes which this process really did cause to
> +Attempt to count the number of bytes which this process and its waited-for children 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
> +Attempt to count the number of bytes which this process and its waited-for children caused to be sent to
> the storage layer.
> .TP
> .IR cancelled_write_bytes :
> @@ -73,7 +73,7 @@ .SH DESCRIPTION
> 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
> +In other words: this field represents the number of bytes which this process and its waited-for children
> caused to not happen, by truncating pagecache.
> A task can cause "negative" I/O too.
> If this task truncates some dirty pagecache,
> --
> 2.39.2
>
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH v2 2/2] proc_pid_io.5: dewafflify
2024-03-13 14:26 [PATCH 1/6] proc_pid_io.5: stats include children наб
` (5 preceding siblings ...)
2024-03-14 16:19 ` [PATCH 1/6] proc_pid_io.5: stats include children Alejandro Colomar
@ 2024-03-17 11:01 ` наб
2024-03-17 12:15 ` Alejandro Colomar
2024-03-17 11:01 ` [PATCH v2 1/2] proc_pid_io.5: stats include children наб
7 siblings, 1 reply; 20+ messages in thread
From: наб @ 2024-03-17 11:01 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: linux-man
[-- Attachment #1: Type: text/plain, Size: 4786 bytes --]
This page copies verbatim the contents of
Documentation/filesystems/proc.rst, added wholesale in
commit f9c99463b0cd05603d125c915e2886d55a686b82 ("[PATCH] Documentation
for io-accounting / reporting via procfs") in 2007.
As such, it mirrors the sensibilities of the time ‒
writing "successful read returns" as "data pulled from storage. actually
just the data the process gave to read(). this also means from non-regular
files! whether the data was pulled from storage doesn't matter actually
(obligatory cache mention)"
for the modern reader this is just a lot of waffling
(note also that processes give no data to read()!)
‒ and sensibilities of the sheepish implementer in kernel documentation ‒
"an attempt" for a well-defined kernel behaviour, mentioning the
"current implementation", consistent mentions of specific kernel-internal
caching mechanisms, "the big inaccuracy here".
Re-write to be more useful and less misleading as documentation;
the syscall enumeration is accurate for kernel v6.8, but the sysc? stats
are also bumped by kernel_{read,write}(), which is sometimes used by too
many syscalls in too many scenarios to usefully enumerate.
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
man5/proc_pid_io.5 | 69 ++++++++++++++++++++--------------------------
1 file changed, 30 insertions(+), 39 deletions(-)
diff --git a/man5/proc_pid_io.5 b/man5/proc_pid_io.5
index dc75a91de..9d1699f6a 100644
--- a/man5/proc_pid_io.5
+++ b/man5/proc_pid_io.5
@@ -32,64 +32,55 @@ .SH DESCRIPTION
.RS
.TP
.IR rchar ": characters read"
-The number of bytes
-which this task and its waited-for children
-have caused to be read from storage.
-This is simply the sum of bytes which this process passed to
+The number of bytes returned by successful
.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 and its waited-for children
-have caused, or shall cause to be written to disk.
-Similar caveats apply here as with
-.IR rchar .
+The number of bytes returned by successful
+.BR write (2)
+and similar system calls.
.TP
.IR syscr ": read syscalls"
-Attempt to count the number of read I/O operations\[em]that is,
-system calls such as
+The number of "I/O read" system calls\[em]those from the
.BR read (2)
+family
+(including when invoked used by the kernel as part of other syscalls),
+.BR sendfile (2),
+.BR copy_file_range (2),
and
-.BR pread (2).
+.BR ioctl (2)
+.BR BTRFS_IOC_ENCODED_READ [ _32 ].
.TP
.IR syscw ": write syscalls"
-Attempt to count the number of write I/O operations\[em]that is,
-system calls such as
+The number of "I/O write" system calls\[em]those from the
.BR write (2)
+family
+(including when invoked used by the kernel as part of other syscalls),
+.BR sendfile (2),
+.BR copy_file_range (2),
and
-.BR pwrite (2).
+.BR ioctl (2)
+.BR BTRFS_IOC_ENCODED_WRITE [ _32 ].
.TP
.IR read_bytes ": bytes read"
-Attempt to count the number of bytes
-which this process and its waited-for children
-really did cause to be fetched from the storage layer.
+The number of bytes really 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 and its waited-for children
-caused to be sent to the storage layer.
+The number of bytes really 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 and its waited-for children
-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.
+The above statistics fail to account for truncation:
+if a process writes 1 MB to a regular file and then removes it,
+said 1 MB will not be written, but
+.I will
+have nevertheless been accounted as a 1 MB write.
+This field represents the number of bytes "saved" from I/O writeback.
+This can yield to having done negative I/O
+if caches dirtied by another process are truncated.
+This figure applies to I/O already accounted-for by
+.IR write_bytes .
.RE
.IP
.IR Note :
--
2.39.2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH v2 2/2] proc_pid_io.5: dewafflify
2024-03-17 11:01 ` [PATCH v2 2/2] proc_pid_io.5: dewafflify наб
@ 2024-03-17 12:15 ` Alejandro Colomar
2024-03-17 13:31 ` [PATCH v3] " наб
0 siblings, 1 reply; 20+ messages in thread
From: Alejandro Colomar @ 2024-03-17 12:15 UTC (permalink / raw)
To: наб; +Cc: linux-man
[-- Attachment #1: Type: text/plain, Size: 5613 bytes --]
Hi!
On Sun, Mar 17, 2024 at 12:01:41PM +0100, наб wrote:
> This page copies verbatim the contents of
> Documentation/filesystems/proc.rst, added wholesale in
> commit f9c99463b0cd05603d125c915e2886d55a686b82 ("[PATCH] Documentation
> for io-accounting / reporting via procfs") in 2007.
>
> As such, it mirrors the sensibilities of the time ‒
> writing "successful read returns" as "data pulled from storage. actually
> just the data the process gave to read(). this also means from non-regular
> files! whether the data was pulled from storage doesn't matter actually
> (obligatory cache mention)"
> for the modern reader this is just a lot of waffling
> (note also that processes give no data to read()!)
> ‒ and sensibilities of the sheepish implementer in kernel documentation ‒
> "an attempt" for a well-defined kernel behaviour, mentioning the
> "current implementation", consistent mentions of specific kernel-internal
> caching mechanisms, "the big inaccuracy here".
>
> Re-write to be more useful and less misleading as documentation;
> the syscall enumeration is accurate for kernel v6.8, but the sysc? stats
> are also bumped by kernel_{read,write}(), which is sometimes used by too
> many syscalls in too many scenarios to usefully enumerate.
>
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> ---
> man5/proc_pid_io.5 | 69 ++++++++++++++++++++--------------------------
> 1 file changed, 30 insertions(+), 39 deletions(-)
>
> diff --git a/man5/proc_pid_io.5 b/man5/proc_pid_io.5
> index dc75a91de..9d1699f6a 100644
> --- a/man5/proc_pid_io.5
> +++ b/man5/proc_pid_io.5
> @@ -32,64 +32,55 @@ .SH DESCRIPTION
> .RS
> .TP
> .IR rchar ": characters read"
> -The number of bytes
> -which this task and its waited-for children
> -have caused to be read from storage.
> -This is simply the sum of bytes which this process passed to
> +The number of bytes returned by successful
In this case, I think I prefer to break before "returned".
What would you do?
> .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 and its waited-for children
> -have caused, or shall cause to be written to disk.
> -Similar caveats apply here as with
> -.IR rchar .
> +The number of bytes returned by successful
> +.BR write (2)
> +and similar system calls.
> .TP
> .IR syscr ": read syscalls"
> -Attempt to count the number of read I/O operations\[em]that is,
> -system calls such as
> +The number of "I/O read" system calls\[em]those from the
From I/O, read only accounts for the I. :)
Should we just say "read"?
> .BR read (2)
> +family
> +(including when invoked used by the kernel as part of other syscalls),
This parenthesis being there seems to imply that if the kernel calls
sendfile internally for $reasons (even if it doesn't at the moment), it
won't be counted. I think it makes more sense at the end of the list,
no?
Cheers,
Alex
P.S.: I restored /^Just/ in the other commit message.
> +.BR sendfile (2),
> +.BR copy_file_range (2),
> and
> -.BR pread (2).
> +.BR ioctl (2)
> +.BR BTRFS_IOC_ENCODED_READ [ _32 ].
> .TP
> .IR syscw ": write syscalls"
> -Attempt to count the number of write I/O operations\[em]that is,
> -system calls such as
> +The number of "I/O write" system calls\[em]those from the
> .BR write (2)
> +family
> +(including when invoked used by the kernel as part of other syscalls),
> +.BR sendfile (2),
> +.BR copy_file_range (2),
> and
> -.BR pwrite (2).
> +.BR ioctl (2)
> +.BR BTRFS_IOC_ENCODED_WRITE [ _32 ].
> .TP
> .IR read_bytes ": bytes read"
> -Attempt to count the number of bytes
> -which this process and its waited-for children
> -really did cause to be fetched from the storage layer.
> +The number of bytes really 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 and its waited-for children
> -caused to be sent to the storage layer.
> +The number of bytes really 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 and its waited-for children
> -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.
> +The above statistics fail to account for truncation:
> +if a process writes 1 MB to a regular file and then removes it,
> +said 1 MB will not be written, but
> +.I will
> +have nevertheless been accounted as a 1 MB write.
> +This field represents the number of bytes "saved" from I/O writeback.
> +This can yield to having done negative I/O
> +if caches dirtied by another process are truncated.
> +This figure applies to I/O already accounted-for by
> +.IR write_bytes .
> .RE
> .IP
> .IR Note :
> --
> 2.39.2
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH v3] proc_pid_io.5: dewafflify
2024-03-17 12:15 ` Alejandro Colomar
@ 2024-03-17 13:31 ` наб
2024-03-17 14:12 ` Alejandro Colomar
0 siblings, 1 reply; 20+ messages in thread
From: наб @ 2024-03-17 13:31 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: linux-man
[-- Attachment #1: Type: text/plain, Size: 6125 bytes --]
This page copies verbatim the contents of
Documentation/filesystems/proc.rst, added wholesale in
commit f9c99463b0cd05603d125c915e2886d55a686b82 ("[PATCH] Documentation
for io-accounting / reporting via procfs") in 2007.
As such, it mirrors the sensibilities of the time ‒
writing "successful read returns" as "data pulled from storage. actually
just the data the process gave to read(). this also means from non-regular
files! whether the data was pulled from storage doesn't matter actually
(obligatory cache mention)"
for the modern reader this is just a lot of waffling
(note also that processes give no data to read()!)
‒ and sensibilities of the sheepish implementer in kernel documentation ‒
"an attempt" for a well-defined kernel behaviour, mentioning the
"current implementation", consistent mentions of specific kernel-internal
caching mechanisms, "the big inaccuracy here".
Re-write to be more useful and less misleading as documentation;
the syscall enumeration is accurate for kernel v6.8, but the sysc? stats
are also bumped by kernel_{read,write}(), which is sometimes used by too
many syscalls in too many scenarios to usefully enumerate.
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
Hi!
On Sun, Mar 17, 2024 at 01:15:18PM +0100, Alejandro Colomar wrote:
> On Sun, Mar 17, 2024 at 12:01:41PM +0100, наб wrote:
> > -The number of bytes
> > -which this task and its waited-for children
> > -have caused to be read from storage.
> > -This is simply the sum of bytes which this process passed to
> > +The number of bytes returned by successful
> In this case, I think I prefer to break before "returned".
> What would you do?
this is a "meh" moment imo; in running text sure, maybe,
but this is broken up by the .BR
so it starts to devolve into 3-word-line territory which is worse
> > -Attempt to count the number of read I/O operations\[em]that is,
> > -system calls such as
> > +The number of "I/O read" system calls\[em]those from the
> From I/O, read only accounts for the I. :)
> Should we just say "read"?
Yeah, "I/O" is overloaded here; "file read" works better.
> > .BR read (2)
> > +family
> > +(including when invoked used by the kernel as part of other syscalls),
> This parenthesis being there seems to imply that if the kernel calls
> sendfile internally for $reasons (even if it doesn't at the moment), it
> won't be counted. I think it makes more sense at the end of the list,
> no?
Well, as-is it doesn't, and I reduced this to the narrowest definition
I can prove, but I guess so, yes.
Also just noticed "invoked used".
man5/proc_pid_io.5 | 67 +++++++++++++++++++++-------------------------
1 file changed, 30 insertions(+), 37 deletions(-)
diff --git a/man5/proc_pid_io.5 b/man5/proc_pid_io.5
index dc75a91de..7f840f3bb 100644
--- a/man5/proc_pid_io.5
+++ b/man5/proc_pid_io.5
@@ -33,63 +33,56 @@ .SH DESCRIPTION
.TP
.IR rchar ": characters read"
The number of bytes
-which this task and its waited-for children
-have caused to be read from storage.
-This is simply the sum of bytes which this process passed to
+returned by successful
.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 and its waited-for children
-have caused, or shall cause to be written to disk.
-Similar caveats apply here as with
-.IR rchar .
+returned by successful
+.BR write (2)
+and similar system calls.
.TP
.IR syscr ": read syscalls"
-Attempt to count the number of read I/O operations\[em]that is,
-system calls such as
+The number of "file read" system calls\[em]those from the
.BR read (2)
+family
+.BR sendfile (2),
+.BR copy_file_range (2),
and
-.BR pread (2).
+.BR ioctl (2)
+.BR BTRFS_IOC_ENCODED_READ [ _32 ]
+(including when invoked by the kernel as part of other syscalls),
.TP
.IR syscw ": write syscalls"
-Attempt to count the number of write I/O operations\[em]that is,
-system calls such as
+The number of "file write" system calls\[em]those from the
.BR write (2)
+family
+.BR sendfile (2),
+.BR copy_file_range (2),
and
-.BR pwrite (2).
+.BR ioctl (2)
+.BR BTRFS_IOC_ENCODED_WRITE [ _32 ]
+(including when invoked by the kernel as part of other syscalls),
.TP
.IR read_bytes ": bytes read"
-Attempt to count the number of bytes
-which this process and its waited-for children
-really did cause to be fetched from the storage layer.
+The number of bytes really 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 and its waited-for children
-caused to be sent to the storage layer.
+The number of bytes really 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 and its waited-for children
-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.
+The above statistics fail to account for truncation:
+if a process writes 1 MB to a regular file and then removes it,
+said 1 MB will not be written, but
+.I will
+have nevertheless been accounted as a 1 MB write.
+This field represents the number of bytes "saved" from I/O writeback.
+This can yield to having done negative I/O
+if caches dirtied by another process are truncated.
+This figure applies to I/O already accounted-for by
+.IR write_bytes .
.RE
.IP
.IR Note :
--
2.39.2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH v3] proc_pid_io.5: dewafflify
2024-03-17 13:31 ` [PATCH v3] " наб
@ 2024-03-17 14:12 ` Alejandro Colomar
2024-03-17 15:37 ` [PATCH v4] " наб
0 siblings, 1 reply; 20+ messages in thread
From: Alejandro Colomar @ 2024-03-17 14:12 UTC (permalink / raw)
To: наб; +Cc: linux-man
[-- Attachment #1: Type: text/plain, Size: 5571 bytes --]
On Sun, Mar 17, 2024 at 02:31:21PM +0100, наб wrote:
[...]
>
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> ---
> Hi!
Hi!
> On Sun, Mar 17, 2024 at 01:15:18PM +0100, Alejandro Colomar wrote:
> > On Sun, Mar 17, 2024 at 12:01:41PM +0100, наб wrote:
> > > -The number of bytes
> > > -which this task and its waited-for children
> > > -have caused to be read from storage.
> > > -This is simply the sum of bytes which this process passed to
> > > +The number of bytes returned by successful
> > In this case, I think I prefer to break before "returned".
> > What would you do?
> this is a "meh" moment imo; in running text sure, maybe,
> but this is broken up by the .BR
> so it starts to devolve into 3-word-line territory which is worse
Hmm, the good part is that the diff doesn't include the first part of
the sentence.
> > > -Attempt to count the number of read I/O operations\[em]that is,
> > > -system calls such as
> > > +The number of "I/O read" system calls\[em]those from the
> > From I/O, read only accounts for the I. :)
> > Should we just say "read"?
> Yeah, "I/O" is overloaded here; "file read" works better.
>
> > > .BR read (2)
> > > +family
> > > +(including when invoked used by the kernel as part of other syscalls),
> > This parenthesis being there seems to imply that if the kernel calls
> > sendfile internally for $reasons (even if it doesn't at the moment), it
> > won't be counted. I think it makes more sense at the end of the list,
> > no?
> Well, as-is it doesn't, and I reduced this to the narrowest definition
> I can prove, but I guess so, yes.
>
> Also just noticed "invoked used".
>
> man5/proc_pid_io.5 | 67 +++++++++++++++++++++-------------------------
> 1 file changed, 30 insertions(+), 37 deletions(-)
>
> diff --git a/man5/proc_pid_io.5 b/man5/proc_pid_io.5
> index dc75a91de..7f840f3bb 100644
> --- a/man5/proc_pid_io.5
> +++ b/man5/proc_pid_io.5
> @@ -33,63 +33,56 @@ .SH DESCRIPTION
> .TP
> .IR rchar ": characters read"
> The number of bytes
> -which this task and its waited-for children
> -have caused to be read from storage.
> -This is simply the sum of bytes which this process passed to
> +returned by successful
> .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 and its waited-for children
> -have caused, or shall cause to be written to disk.
> -Similar caveats apply here as with
> -.IR rchar .
> +returned by successful
> +.BR write (2)
> +and similar system calls.
> .TP
> .IR syscr ": read syscalls"
> -Attempt to count the number of read I/O operations\[em]that is,
> -system calls such as
> +The number of "file read" system calls\[em]those from the
> .BR read (2)
> +family
> +.BR sendfile (2),
> +.BR copy_file_range (2),
> and
> -.BR pread (2).
> +.BR ioctl (2)
> +.BR BTRFS_IOC_ENCODED_READ [ _32 ]
> +(including when invoked by the kernel as part of other syscalls),
s/,/./
> .TP
> .IR syscw ": write syscalls"
> -Attempt to count the number of write I/O operations\[em]that is,
> -system calls such as
> +The number of "file write" system calls\[em]those from the
> .BR write (2)
> +family
> +.BR sendfile (2),
> +.BR copy_file_range (2),
> and
> -.BR pwrite (2).
> +.BR ioctl (2)
> +.BR BTRFS_IOC_ENCODED_WRITE [ _32 ]
> +(including when invoked by the kernel as part of other syscalls),
s/,/./
> .TP
> .IR read_bytes ": bytes read"
> -Attempt to count the number of bytes
> -which this process and its waited-for children
> -really did cause to be fetched from the storage layer.
> +The number of bytes really 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 and its waited-for children
> -caused to be sent to the storage layer.
> +The number of bytes really 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 and its waited-for children
> -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.
> +The above statistics fail to account for truncation:
> +if a process writes 1 MB to a regular file and then removes it,
> +said 1 MB will not be written, but
> +.I will
> +have nevertheless been accounted as a 1 MB write.
> +This field represents the number of bytes "saved" from I/O writeback.
> +This can yield to having done negative I/O
> +if caches dirtied by another process are truncated.
> +This figure applies to I/O already accounted-for by
> +.IR write_bytes .
I'm not sure I understand this last sentence. What does "this figure"
refer to exactly?
Have a lovely day!
Alex
> .RE
> .IP
> .IR Note :
> --
> 2.39.2
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v4] proc_pid_io.5: dewafflify
2024-03-17 14:12 ` Alejandro Colomar
@ 2024-03-17 15:37 ` наб
2024-03-17 16:08 ` Alejandro Colomar
0 siblings, 1 reply; 20+ messages in thread
From: наб @ 2024-03-17 15:37 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: linux-man
[-- Attachment #1: Type: text/plain, Size: 4747 bytes --]
This page copies verbatim the contents of
Documentation/filesystems/proc.rst, added wholesale in
commit f9c99463b0cd05603d125c915e2886d55a686b82 ("[PATCH] Documentation
for io-accounting / reporting via procfs") in 2007.
As such, it mirrors the sensibilities of the time ‒
writing "successful read returns" as "data pulled from storage. actually
just the data the process gave to read(). this also means from non-regular
files! whether the data was pulled from storage doesn't matter actually
(obligatory cache mention)"
for the modern reader this is just a lot of waffling
(note also that processes give no data to read()!)
‒ and sensibilities of the sheepish implementer in kernel documentation ‒
"an attempt" for a well-defined kernel behaviour, mentioning the
"current implementation", consistent mentions of specific kernel-internal
caching mechanisms, "the big inaccuracy here".
Re-write to be more useful and less misleading as documentation;
the syscall enumeration is accurate for kernel v6.8, but the sysc? stats
are also bumped by kernel_{read,write}(), which is sometimes used by too
many syscalls in too many scenarios to usefully enumerate.
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
man5/proc_pid_io.5 | 68 +++++++++++++++++++++-------------------------
1 file changed, 31 insertions(+), 37 deletions(-)
diff --git a/man5/proc_pid_io.5 b/man5/proc_pid_io.5
index dc75a91de..531de8c0d 100644
--- a/man5/proc_pid_io.5
+++ b/man5/proc_pid_io.5
@@ -33,63 +33,57 @@ .SH DESCRIPTION
.TP
.IR rchar ": characters read"
The number of bytes
-which this task and its waited-for children
-have caused to be read from storage.
-This is simply the sum of bytes which this process passed to
+returned by successful
.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 and its waited-for children
-have caused, or shall cause to be written to disk.
-Similar caveats apply here as with
-.IR rchar .
+returned by successful
+.BR write (2)
+and similar system calls.
.TP
.IR syscr ": read syscalls"
-Attempt to count the number of read I/O operations\[em]that is,
-system calls such as
+The number of "file read" system calls\[em]those from the
.BR read (2)
+family,
+.BR sendfile (2),
+.BR copy_file_range (2),
and
-.BR pread (2).
+.BR ioctl (2)
+.BR BTRFS_IOC_ENCODED_READ [ _32 ]
+(including when invoked by the kernel as part of other syscalls).
.TP
.IR syscw ": write syscalls"
-Attempt to count the number of write I/O operations\[em]that is,
-system calls such as
+The number of "file write" system calls\[em]those from the
.BR write (2)
+family,
+.BR sendfile (2),
+.BR copy_file_range (2),
and
-.BR pwrite (2).
+.BR ioctl (2)
+.BR BTRFS_IOC_ENCODED_WRITE [ _32 ]
+(including when invoked by the kernel as part of other syscalls).
.TP
.IR read_bytes ": bytes read"
-Attempt to count the number of bytes
-which this process and its waited-for children
-really did cause to be fetched from the storage layer.
+The number of bytes really 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 and its waited-for children
-caused to be sent to the storage layer.
+The number of bytes really 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 and its waited-for children
-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.
+The above statistics fail to account for truncation:
+if a process writes 1 MB to a regular file and then removes it,
+said 1 MB will not be written, but
+.I will
+have nevertheless been accounted as a 1 MB write.
+This field represents the number of bytes "saved" from I/O writeback.
+This can yield to having done negative I/O
+if caches dirtied by another process are truncated.
+.I cancelled_write_bytes
+applies to I/O already accounted-for in
+.IR write_bytes .
.RE
.IP
.IR Note :
--
2.39.2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH v4] proc_pid_io.5: dewafflify
2024-03-17 15:37 ` [PATCH v4] " наб
@ 2024-03-17 16:08 ` Alejandro Colomar
0 siblings, 0 replies; 20+ messages in thread
From: Alejandro Colomar @ 2024-03-17 16:08 UTC (permalink / raw)
To: наб; +Cc: linux-man
[-- Attachment #1: Type: text/plain, Size: 5172 bytes --]
On Sun, Mar 17, 2024 at 04:37:52PM +0100, наб wrote:
> This page copies verbatim the contents of
> Documentation/filesystems/proc.rst, added wholesale in
> commit f9c99463b0cd05603d125c915e2886d55a686b82 ("[PATCH] Documentation
> for io-accounting / reporting via procfs") in 2007.
>
> As such, it mirrors the sensibilities of the time ‒
> writing "successful read returns" as "data pulled from storage. actually
> just the data the process gave to read(). this also means from non-regular
> files! whether the data was pulled from storage doesn't matter actually
> (obligatory cache mention)"
> for the modern reader this is just a lot of waffling
> (note also that processes give no data to read()!)
> ‒ and sensibilities of the sheepish implementer in kernel documentation ‒
> "an attempt" for a well-defined kernel behaviour, mentioning the
> "current implementation", consistent mentions of specific kernel-internal
> caching mechanisms, "the big inaccuracy here".
>
> Re-write to be more useful and less misleading as documentation;
> the syscall enumeration is accurate for kernel v6.8, but the sysc? stats
> are also bumped by kernel_{read,write}(), which is sometimes used by too
> many syscalls in too many scenarios to usefully enumerate.
>
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Hi!
Patch applied. Thanks.
Have a lovely day!
Alex
> ---
> man5/proc_pid_io.5 | 68 +++++++++++++++++++++-------------------------
> 1 file changed, 31 insertions(+), 37 deletions(-)
>
> diff --git a/man5/proc_pid_io.5 b/man5/proc_pid_io.5
> index dc75a91de..531de8c0d 100644
> --- a/man5/proc_pid_io.5
> +++ b/man5/proc_pid_io.5
> @@ -33,63 +33,57 @@ .SH DESCRIPTION
> .TP
> .IR rchar ": characters read"
> The number of bytes
> -which this task and its waited-for children
> -have caused to be read from storage.
> -This is simply the sum of bytes which this process passed to
> +returned by successful
> .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 and its waited-for children
> -have caused, or shall cause to be written to disk.
> -Similar caveats apply here as with
> -.IR rchar .
> +returned by successful
> +.BR write (2)
> +and similar system calls.
> .TP
> .IR syscr ": read syscalls"
> -Attempt to count the number of read I/O operations\[em]that is,
> -system calls such as
> +The number of "file read" system calls\[em]those from the
> .BR read (2)
> +family,
> +.BR sendfile (2),
> +.BR copy_file_range (2),
> and
> -.BR pread (2).
> +.BR ioctl (2)
> +.BR BTRFS_IOC_ENCODED_READ [ _32 ]
> +(including when invoked by the kernel as part of other syscalls).
> .TP
> .IR syscw ": write syscalls"
> -Attempt to count the number of write I/O operations\[em]that is,
> -system calls such as
> +The number of "file write" system calls\[em]those from the
> .BR write (2)
> +family,
> +.BR sendfile (2),
> +.BR copy_file_range (2),
> and
> -.BR pwrite (2).
> +.BR ioctl (2)
> +.BR BTRFS_IOC_ENCODED_WRITE [ _32 ]
> +(including when invoked by the kernel as part of other syscalls).
> .TP
> .IR read_bytes ": bytes read"
> -Attempt to count the number of bytes
> -which this process and its waited-for children
> -really did cause to be fetched from the storage layer.
> +The number of bytes really 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 and its waited-for children
> -caused to be sent to the storage layer.
> +The number of bytes really 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 and its waited-for children
> -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.
> +The above statistics fail to account for truncation:
> +if a process writes 1 MB to a regular file and then removes it,
> +said 1 MB will not be written, but
> +.I will
> +have nevertheless been accounted as a 1 MB write.
> +This field represents the number of bytes "saved" from I/O writeback.
> +This can yield to having done negative I/O
> +if caches dirtied by another process are truncated.
> +.I cancelled_write_bytes
> +applies to I/O already accounted-for in
> +.IR write_bytes .
> .RE
> .IP
> .IR Note :
> --
> 2.39.2
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v2 1/2] proc_pid_io.5: stats include children
2024-03-13 14:26 [PATCH 1/6] proc_pid_io.5: stats include children наб
` (6 preceding siblings ...)
2024-03-17 11:01 ` [PATCH v2 2/2] proc_pid_io.5: dewafflify наб
@ 2024-03-17 11:01 ` наб
2024-03-17 11:39 ` Alejandro Colomar
7 siblings, 1 reply; 20+ messages in thread
From: наб @ 2024-03-17 11:01 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: linux-man
[-- Attachment #1: Type: text/plain, Size: 4346 bytes --]
This file is like getrusage(2) RUSAGE_SELF + RUSAGE_CHILDREN,
the current wording implies it's like just RUSAGE_SELF.
Compare:
#include <fcntl.h>
#include <signal.h>
#include <string.h>
#include <sys/wait.h>
#include <unistd.h>
void copy() {
char buf[1024];
int fd = open("/proc/self/io", 0);
write(1, buf, read(fd, buf, sizeof(buf)));
close(fd);
}
int main() {
copy();
copy();
if (!fork()) {
zero:;
int fd = open("/dev/zero", 0);
char buf[64 * 1024] = {};
write(1, buf, 10000);
for (int i = 0; i < 1000; ++i)
read(fd, buf, sizeof(buf));
_exit(0);
}
sleep(1);
copy();
wait(NULL);
copy();
signal(SIGCHLD, SIG_IGN);
if (!fork())
goto zero;
sleep(1);
copy();
wait(NULL);
copy();
}
yielding
rchar: 3980
wchar: 0
syscr: 9
syscw: 0
read_bytes: 2968
write_bytes: 0
cancelled_write_bytes: 0
rchar: 4076
wchar: 96
syscr: 10
syscw: 1
read_bytes: 2968
write_bytes: 96
cancelled_write_bytes: 0
rchar: 4175
wchar: 195
syscr: 11
syscw: 2
read_bytes: 2968
write_bytes: 195
cancelled_write_bytes: 0
rchar: 65540276
wchar: 10296
syscr: 1012
syscw: 4
read_bytes: 2968
write_bytes: 10296
cancelled_write_bytes: 0
rchar: 65540387
wchar: 10407
syscr: 1013
syscw: 5
read_bytes: 2968
write_bytes: 10407
cancelled_write_bytes: 0
rchar: 65540498
wchar: 10518
syscr: 1014
syscw: 6
read_bytes: 2968
write_bytes: 10518
cancelled_write_bytes: 0
Just s/process/& and its waited-for children/ but re-broken per review.
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
man5/proc_pid_io.5 | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/man5/proc_pid_io.5 b/man5/proc_pid_io.5
index d6eaebf5d..dc75a91de 100644
--- a/man5/proc_pid_io.5
+++ b/man5/proc_pid_io.5
@@ -11,7 +11,9 @@ .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:
+This file contains I/O statistics
+for the process and its waited-for children,
+for example:
.IP
.in +4n
.EX
@@ -30,7 +32,9 @@ .SH DESCRIPTION
.RS
.TP
.IR rchar ": characters read"
-The number of bytes which this task has caused to be read from storage.
+The number of bytes
+which this task and its waited-for children
+have 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.
@@ -40,8 +44,9 @@ .SH DESCRIPTION
pagecache).
.TP
.IR wchar ": characters written"
-The number of bytes which this task has caused, or shall cause to be written
-to disk.
+The number of bytes
+which this task and its waited-for children
+have caused, or shall cause to be written to disk.
Similar caveats apply here as with
.IR rchar .
.TP
@@ -60,20 +65,24 @@ .SH DESCRIPTION
.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.
+Attempt to count the number of bytes
+which this process and its waited-for children
+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.
+Attempt to count the number of bytes
+which this process and its waited-for children
+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
+In other words:
+this field represents the number of bytes
+which this process and its waited-for children
caused to not happen, by truncating pagecache.
A task can cause "negative" I/O too.
If this task truncates some dirty pagecache,
--
2.39.2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH v2 1/2] proc_pid_io.5: stats include children
2024-03-17 11:01 ` [PATCH v2 1/2] proc_pid_io.5: stats include children наб
@ 2024-03-17 11:39 ` Alejandro Colomar
0 siblings, 0 replies; 20+ messages in thread
From: Alejandro Colomar @ 2024-03-17 11:39 UTC (permalink / raw)
To: наб; +Cc: linux-man
[-- Attachment #1: Type: text/plain, Size: 3069 bytes --]
Hi наб!
On Sun, Mar 17, 2024 at 12:01:43PM +0100, наб wrote:
[...]
> Just s/process/& and its waited-for children/ but re-broken per review.
>
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Patch applied. (And /^Just/d ) Thanks!
Have a lovely day!
Alex
> ---
> man5/proc_pid_io.5 | 27 ++++++++++++++++++---------
> 1 file changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/man5/proc_pid_io.5 b/man5/proc_pid_io.5
> index d6eaebf5d..dc75a91de 100644
> --- a/man5/proc_pid_io.5
> +++ b/man5/proc_pid_io.5
> @@ -11,7 +11,9 @@ .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:
> +This file contains I/O statistics
> +for the process and its waited-for children,
> +for example:
> .IP
> .in +4n
> .EX
> @@ -30,7 +32,9 @@ .SH DESCRIPTION
> .RS
> .TP
> .IR rchar ": characters read"
> -The number of bytes which this task has caused to be read from storage.
> +The number of bytes
> +which this task and its waited-for children
> +have 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.
> @@ -40,8 +44,9 @@ .SH DESCRIPTION
> pagecache).
> .TP
> .IR wchar ": characters written"
> -The number of bytes which this task has caused, or shall cause to be written
> -to disk.
> +The number of bytes
> +which this task and its waited-for children
> +have caused, or shall cause to be written to disk.
> Similar caveats apply here as with
> .IR rchar .
> .TP
> @@ -60,20 +65,24 @@ .SH DESCRIPTION
> .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.
> +Attempt to count the number of bytes
> +which this process and its waited-for children
> +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.
> +Attempt to count the number of bytes
> +which this process and its waited-for children
> +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
> +In other words:
> +this field represents the number of bytes
> +which this process and its waited-for children
> caused to not happen, by truncating pagecache.
> A task can cause "negative" I/O too.
> If this task truncates some dirty pagecache,
> --
> 2.39.2
>
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread