Re: negative dentries wasting ram

[Andrea Arcangeli <andrea@suse.de>]

On Fri, May 24, 2002 at 01:04:33PM -0400, Alexander Viro wrote:
> 
> 
> On Fri, 24 May 2002, Andrea Arcangeli wrote:
> 
> > > Note that this will have to touch the FS anyway, since the O_CREAT thing
> > > forces a call down to the FS to actually create the file.
> > 
> > yep. the only case where it could provide some in-core "caching"
> > positive effect is:
> > 
> > 	unlink
> > 	open(w/o creat)
> > 
> > but I don't see it as a common case.
> 
> 	Guys, how about tracing the damn thing and checking what actually
> happens?  Or, at least, checking the prototypes and noticing that ->create()
> takes (hashed) dentry as an argument, so if unlinked on had been freed we _must_
> call ->lookup().

so why don't you also left a negative directory floating around, so you
know if you creat a file with such name you don't need to ->loopup the
lowlevel fs but you only need to destroy the negative directory and all
its leafs in-core-dcache? If you did the negative effect would become
more obvious, the d_unhash hides it except for the spooling workloads.

Avoiding a lowlevel lookup operation for an unlink/open cycle, looks a
minor optimization compared to a massive dcache ""leak"" under certain
common spooling workloads IMHO.

Anyways in 2.5 we could still take advantage of the negative dentries as
much as possible (also after unlink) by moving the negative dentries
into a separate list and by putting the shrinkage of this list in front
of kmem_cache_reap, so we are as efficient as possible, but we don't
risk throwing away very useful cache, for more dubious caching effects
after an unlink/create-failure that currently have the side effect of
throwing away tons of worthwhile positive pagecache (and even triggering
swap false positives) in some workloads.

Andrea