On Sat, Jul 23, 2022 at 12:29 AM Luis Chamberlain <mcgrof@xxxxxxxxxx> 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@xxxxxxxxxxxxx > Reported-by: Zhang Yuchen <zhangyuchen.lcr@xxxxxxxxxxxxx> > Signed-off-by: Luis Chamberlain <mcgrof@xxxxxxxxxx> > --- > 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 >
