Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: negative dentries wasting ram
Original-Message-ID: <Pine.LNX.4.44.0205240737400.26171-100000@home.transmeta.com>
Date: Fri, 24 May 2002 14:44:20 GMT
Message-ID: <fa.l2t3niv.1n1829q@ifi.uio.no>

On Fri, 24 May 2002, Andrea Arcangeli wrote:
>
> Negative dentries should be only temporary entities, for example between
> the allocation of the dentry and the create of the inode, they shouldn't
> be left around waiting the vm to collect them.

Wrong. Negative dentries are very useful for caching negative lookups:
look at the average startup sequence of any program linked with glibc, and
depending on your setup you will notice how it tries to open a _lot_ of a
files that do not exist (the "depending on your setup" comes from the fact
that it depends on things like how quickly it finds your "locale" setup
from its locale path - you may have one of the setups that puts it in the
first location glibc searches etc).

If you don't cache those negative lookups, you will do a low-level
filesystem lookup for each of those failures, which is _expensive_.

However, you're right that it probably doesn't help to do this after
"unlink()" - it's probably only worth doing when actually doing a
"lookup()" that fails.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: negative dentries wasting ram
Original-Message-ID: <Pine.LNX.4.44.0205240927580.11495-100000@home.transmeta.com>
Date: Fri, 24 May 2002 16:31:05 GMT
Message-ID: <fa.l4tdo2v.1k1a39k@ifi.uio.no>

On Fri, 24 May 2002, Alexander Viro wrote:
>
> On Fri, 24 May 2002, Linus Torvalds wrote:
>
> > However, you're right that it probably doesn't help to do this after
> > "unlink()" - it's probably only worth doing when actually doing a
> > "lookup()" that fails.
>
> Depends on many things, including the amount of userland code that does
> 	unlink(name);
> 	open(name, O_CREAT|O_EXCL..., ...);

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.

The only think we save is a dentry kfree/kmalloc in this case, not a FS
downcall. And I think Andrea is right that it can waste memory for the
likely much more common case where the file just stays removed.

		Linus