Re: Re: [PATCH v2] dcache: add fs.dentry-limit sysctl with negative-first reaper

[Horst Birthelmer]

On Sun, May 17, 2026 at 12:09:26AM +0100, Matthew Wilcox wrote:
> On Sat, May 16, 2026 at 04:52:54PM +0200, Horst Birthelmer wrote:
> > There was a discussion at LSFMM about servers with too many cached
> > negative dentries.
> > That gave me the idea to keep the dentries in general limited
> > if the system administrator needs it to.
> 
> I feel you should link to the dozens of previous attempts at this kind
> of thing to show that you're aware that this has been tried before and
> you're doing something meaningfully different.
> 

Hi Matthew,

thanks for looking at this.

- The first limitation of dentries I could find was a patch for Linux 2.6.7
which introduced the vfs_cache_pressure option. [1]
This is still in use today but will not limit dentries as such just the
relation of where to release the pressure but you have to get into a pressure
situation for it to actually matter.
For my case when we get into pressure the fuse server could already be in heavy
trouble (we have had OOM events for the cgroup due to this)

- in 2011 there was the attempt to limit dentries by container [2] [3]
Here Dave Chinner made the point that the dentry cache is usually not the problem
but the inode cache, which is exactly what we see as well, since the fuse server
has to keep a lot of private data for every cached inode. However we have the
information for LRU only for the dentries, so it is the best way we can keep this
under control, limit the number of dentries to an acceptable amounr.

- there was an entire series by Waiman Long starting at around 2017 [4] 
Here even you were part of the discussion, and I think the ideas are very similar,
I'm just more worried about unused dentries (I just prefer negative ones on
reclaim) There are several of different attempts in this context.

- then there was tbe one I mentioned in the cover letter [5]
which was trying to modify the caching to limit the excessing traversing when
there are so many entries.
I'm trying to save the same symptoms but not with that approach at all. I don't
worry at all about the chache structures.

- there was [6] by Gautham Ananthakrishna
Here the focus was on the memory used for the dentries. This is none of my concern
in this patch. I'm trying to just not keep dentries and indirectly inodes 
unnecessarily in the kernel and as a consequence in the fuse server in user space.

- currently we have the possibility via /proc/sys/fs/dentry-negative to disable
negative dentries completely
I am completely agnostic to this. If an admin disables negative dentries I try to
free some by freeing unused ones and make the limit, if not this is no problem.

I'm sure I have probably missed some where the limitation of dentries was a 
secodnary effect. I have searched for patches for fs/dcache.c that had anything
to do with dentries.

--
As a conclusion, I think I have an uncommon perspective on the cache entries
since I don't usually work on vfs but argue from the perspective of a fuse server
Where the kernel makes us waste resources. This hurts way more in the FUSE context
than in a 'normal' file system.
I have taken the look at the dentry cache just because people told me that this
has to be solved in the vfs (and I agree). I actually have a somewhat hacky patch
to do this from fuse and only for the fuse sb.

This patch will start a worker when we pass the set limit and free the negative
dentries then continue on with the unused dentries based on the LRU data.

What I'm trying to achieve is keep only actually used entries in if we are over
an arbitrary limit, and trying not to mess too much with the work that is done
by the kernel. Then there is the point that shrink_dentry_list() is only there
since 2019, so older approaches did not have tthe possibility.

The short version: This is noothing new, just a new combination of already existing
solutions, that could be useful.

[1] https://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7/2.6.7-mm1/broken-out/vfs-shrinkage-tuning.patch
[2] https://lwn.net/Articles/441164/
[3] https://lore.kernel.org/all/4DBFF1AD.90303@xxxxxxxxxxxxx/
[4] https://lore.kernel.org/all/1500298773-7510-1-git-send-email-longman@xxxxxxxxxx/
[5] https://lore.kernel.org/linux-fsdevel/20260331012925.74840-1-raven@xxxxxxxxxx/
[6] https://lore.kernel.org/all/1611235185-1685-1-git-send-email-gautham.ananthakrishna@xxxxxxxxxx/