diff mbox series

[2/2] Documentation/filesystems/proc.rst: document procfs inode timestamps

Message ID 20220722162934.1888835-3-mcgrof@kernel.org (mailing list archive)
State New, archived
Headers show
Series procfs: document proc timestamps | expand

Commit Message

Luis Chamberlain July 22, 2022, 4:29 p.m. UTC
The timestamps for procfs files are not well understood and can
confuse users and developers [0] in particular for the timestamp
for the start time or a process. Clarify what they mean and that
they are a reflection of the ephemeral nature of the filesystem
inodes.

The procfs inodes are created when you first read them and then
stuffed in the page cache. If the page cache and indodes are
reclaimed they can be removed, and re-created with a new timestamp
after read again. Document this little bit of tribal knowledge.

[0] https://lkml.kernel.org/r/20220721081617.36103-1-zhangyuchen.lcr@bytedance.com
Reported-by: Zhang Yuchen <zhangyuchen.lcr@bytedance.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
---
 Documentation/filesystems/proc.rst | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

Comments

Randy Dunlap July 22, 2022, 7:56 p.m. UTC | #1
Hi--

On 7/22/22 09:29, Luis Chamberlain wrote:
> The timestamps for procfs files are not well understood and can
> confuse users and developers [0] in particular for the timestamp
> for the start time or a process. Clarify what they mean and that
> they are a reflection of the ephemeral nature of the filesystem
> inodes.
> 
> The procfs inodes are created when you first read them and then
> stuffed in the page cache. If the page cache and indodes are
> reclaimed they can be removed, and re-created with a new timestamp
> after read again. Document this little bit of tribal knowledge.
> 
> [0] https://lkml.kernel.org/r/20220721081617.36103-1-zhangyuchen.lcr@bytedance.com
> Reported-by: Zhang Yuchen <zhangyuchen.lcr@bytedance.com>
> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
> ---
>  Documentation/filesystems/proc.rst | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
> index 9fd5249f1a5f..9defe9af683a 100644
> --- a/Documentation/filesystems/proc.rst
> +++ b/Documentation/filesystems/proc.rst
> @@ -59,6 +59,15 @@ The proc  file  system acts as an interface to internal data structures in the
>  kernel. It  can  be  used to obtain information about the system and to change
>  certain kernel parameters at runtime (sysctl).
>  
> +The proc files are dynamic in nature and allow for developers to make the

Awkward. How about:

   The proc files are dynamic and allow for the content to be changed each time
   a file is read.

> +content to be changed each time a file is read. The proc files and directories

                                                   The proc files and directory

> +inodes are created when someone first reads a respective proc file or directory,
> +as such the timestamps of the proc files reflect this time. As with other
> +filesystems, these proc inodes can be removed through reclaim under memory
> +pressure and so the timestamps of the proc files can change if the proc files
> +are destroyed and re-created (echo 3 > /proc/sys/vm/drop_caches forces and
> +illustrate the reclaim of inodes and page cache).
> +
>  First, we'll  take  a  look  at the read-only parts of /proc. In Chapter 2, we
>  show you how you can use /proc/sys to change settings.

Thanks.
Muchun Song July 23, 2022, 2:17 p.m. UTC | #2
On Sat, Jul 23, 2022 at 12:29 AM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> The timestamps for procfs files are not well understood and can
> confuse users and developers [0] in particular for the timestamp
> for the start time or a process. Clarify what they mean and that
> they are a reflection of the ephemeral nature of the filesystem
> inodes.
>
> The procfs inodes are created when you first read them and then
> stuffed in the page cache. If the page cache and indodes are
> reclaimed they can be removed, and re-created with a new timestamp
> after read again. Document this little bit of tribal knowledge.
>
> [0] https://lkml.kernel.org/r/20220721081617.36103-1-zhangyuchen.lcr@bytedance.com
> Reported-by: Zhang Yuchen <zhangyuchen.lcr@bytedance.com>
> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
> ---
>  Documentation/filesystems/proc.rst | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
> index 9fd5249f1a5f..9defe9af683a 100644
> --- a/Documentation/filesystems/proc.rst
> +++ b/Documentation/filesystems/proc.rst
> @@ -59,6 +59,15 @@ The proc  file  system acts as an interface to internal data structures in the
>  kernel. It  can  be  used to obtain information about the system and to change
>  certain kernel parameters at runtime (sysctl).
>
> +The proc files are dynamic in nature and allow for developers to make the
> +content to be changed each time a file is read. The proc files and directories
> +inodes are created when someone first reads a respective proc file or directory,
> +as such the timestamps of the proc files reflect this time. As with other
> +filesystems, these proc inodes can be removed through reclaim under memory
> +pressure and so the timestamps of the proc files can change if the proc files
> +are destroyed and re-created (echo 3 > /proc/sys/vm/drop_caches forces and
> +illustrate the reclaim of inodes and page cache).

Thanks for fixing this.

> +
>  First, we'll  take  a  look  at the read-only parts of /proc. In Chapter 2, we
>  show you how you can use /proc/sys to change settings.
>
> @@ -328,6 +337,13 @@ It's slow but very precise.
>                 system call
>    ============= ===============================================================
>
> +Note that the start_time inside the stat file is different than the timestamp
> +of the stat file itself. The timestamp of the stat file simply reflects the
> +first time the stat file was read. The proc inode for this file can be reclaimed
> +under memory pressure and be recreated after this and so the timestamp can
> +change. Userspace should rely on the start_time entry in the the stat file to
> +get a process start time.
> +

I'm not sure the value of those comments since the above description
is already enough to tell people the timestamp of /proc files or directories
can be changed in some cases, which already includes the case of
/proc/PID/stat.

If we really want to take /proc/PID/stat as an example to show the
timestamp is unstable, I think it is better to move those comments to the
above section where you explain why the timestamp can be changed .

Thanks.

>  The /proc/PID/maps file contains the currently mapped memory regions and
>  their access permissions.
>
> --
> 2.35.1
>
diff mbox series

Patch

diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
index 9fd5249f1a5f..9defe9af683a 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -59,6 +59,15 @@  The proc  file  system acts as an interface to internal data structures in the
 kernel. It  can  be  used to obtain information about the system and to change
 certain kernel parameters at runtime (sysctl).
 
+The proc files are dynamic in nature and allow for developers to make the
+content to be changed each time a file is read. The proc files and directories
+inodes are created when someone first reads a respective proc file or directory,
+as such the timestamps of the proc files reflect this time. As with other
+filesystems, these proc inodes can be removed through reclaim under memory
+pressure and so the timestamps of the proc files can change if the proc files
+are destroyed and re-created (echo 3 > /proc/sys/vm/drop_caches forces and
+illustrate the reclaim of inodes and page cache).
+
 First, we'll  take  a  look  at the read-only parts of /proc. In Chapter 2, we
 show you how you can use /proc/sys to change settings.
 
@@ -328,6 +337,13 @@  It's slow but very precise.
 		system call
   ============= ===============================================================
 
+Note that the start_time inside the stat file is different than the timestamp
+of the stat file itself. The timestamp of the stat file simply reflects the
+first time the stat file was read. The proc inode for this file can be reclaimed
+under memory pressure and be recreated after this and so the timestamp can
+change. Userspace should rely on the start_time entry in the the stat file to
+get a process start time.
+
 The /proc/PID/maps file contains the currently mapped memory regions and
 their access permissions.