From d9515637ca709f2ad9fbb4e1e90690981b8db1ad Mon Sep 17 00:00:00 2001 From: Andre Noll Date: Thu, 26 Mar 2020 11:06:15 +0100 Subject: [PATCH] Filesystems: Improve section on dentry cache. --- Filesystems.m4 | 34 +++++++++++++++++++--------------- 1 file changed, 19 insertions(+), 15 deletions(-) diff --git a/Filesystems.m4 b/Filesystems.m4 index 0e573d3..9035de5 100644 --- a/Filesystems.m4 +++ b/Filesystems.m4 @@ -543,30 +543,34 @@ SUBSECTION(«The Dentry Cache») which represents a file or a directory. Dentries contain pointers to the corresponding inode and to the parent dentry. The vfs maintains the dentry cache, which is independent of the normal page -cache that keeps copies of file contents in memory. Dentries are kept -in hashed lists to make directory lookups fast.

+cache that keeps copies of file contents in memory. Dentries are +kept in hashed lists to make directory lookups fast. Dentries are +also reference-counted. As long as there is a reference on a dentry, +it can not be pruned from the dentry cache. Unreferenced dentries, +however, can be evicted from the cache at any time due to memory +pressure. Each dentry also has a "looked up" flag which enables the +VFS to evict dentries which have never been looked up earlier than +those which have.

On a busy system the dentry cache changes frequently. For example, file creation, removal and rename all trigger an update of the dentry -cache. Moreover, memory pressure can cause dentries to be evicted from -the cache at any time. Clearly, some sort of coordination is needed to -keep the dentry cache consistent in view of concurrent changes, like -a file being deleted on one CPU and looked up on another. A global -lock would scale very poorly, so a more sophisticated method called -RCU-walk is employed. With RCU, lookups can be performed -without taking locks, and read operations can proceed in parallel -with concurrent writers.

+cache. Clearly, some sort of coordination is needed to keep the dentry +cache consistent in view of concurrent changes, like a file being +deleted on one CPU and looked up on another. A global lock would scale +very poorly, so a more sophisticated method called RCU-walk is +employed. With RCU, lookups can be performed without taking locks, and +read operations can proceed in parallel with concurrent writers.

The dentry cache also contains negative entries which represent nonexistent paths which were recently looked up unsuccessfully. When a user space program tries to access such a path again, the ENOENT error can be returned without involving the filesystem. Since lookups of nonexistent files happen frequently, -failing such lookups quickly enhances performance. Naturally, negative -dentries do not point to any inode.

- -

Dentries are reference-counted. As long as there is a reference -on a dentry, it can not be pruned from the dentry cache.

+failing such lookups quickly enhances performance. For example +import statements from interpreted languages like Python +benefit from the negative entries of the dentry cache because the +requested files have to be looked up in several directories. Naturally, +negative dentries do not point to any inode.

SUBSECTION(«File and Inode Objects») -- 2.30.2