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

[Jan Kara]

Hi Horst!

On Sun 17-05-26 09:57:41, Horst Birthelmer wrote:
> 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.

<snip>

> 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.

So I'm a bit confused here. The changelog speaks only about negative
dentries (and that's what the change also concentrates on). OTOH you've
mentioned multiple times that you are not really interested in limiting
negative dentries but rather positive ones because you have a problem with
cached inodes. So can you perhaps formulate what is exactly the problem
you're trying to solve?

Also you mention that cached (positive) dentries and inodes are a wasted
memory when they aren't used. That is certainly a valid view, OTOH you can
never predict future so you don't really know what will get used in the
future and thus will be useful. That's why we currently side with the idea
that memory that isn't used for something is wasted and unless there's
something to use the memory for, we cache dentries & inodes & page cache in
it.

If I remember correctly the discussion we had at LSF, the problem why inode
caching is a problem for you, although there's enough free memory and no
memory pressure, is that these cached inodes pin memory on the other end of
the FUSE communication channel and there we are getting short on memory. Is
this what you're trying to solve?

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR