Positive to negative ratio [LWN.net]

Positive to negative ratio

Posted Jul 7, 2026 16:01 UTC (Tue) by kleptog (subscriber, #1183)
In reply to: Positive to negative ratio by farnz
Parent article: Limiting negative dentries

ISTM what is relevant is the amount of time a dentry is in the cache. Deleting a negative dentry means the next lookup will take longer. So that's the time being saved that needs to be weighed against the extra memory usage and CPU cost of keeping the entry.

I would think that if a negative dentry hasn't been hit in the last minute you can probably toss it. The example posted above where the negative dentries are using up 1GB of memory per minute while never being referenced for me feels like the memory costs far outweighs the benefits.

to post comments

Positive to negative ratio

Posted Jul 7, 2026 17:15 UTC (Tue) by farnz (subscriber, #17727) [Link]

The same applies to positive dentries, too - while they don't have the cache size explosion potential of negative dentries (being bounded by the number of entries in the directory), it seems wasteful to keep a positive dentry for omp.h that's never referenced again, when you could use the cache space for a negative dentry for limits.h that's being referenced every 90 seconds.

It does feel like the necessary change is to have a size limit on the dentry cache (so that it can't be multiple gigabytes in size), and to have a cache replacement policy that accounts for many dentries never being reused - a split LRU (like the active/inactive lists for page cache), or a LFUDA type policy.

Positive to negative ratio

Posted Jul 7, 2026 18:28 UTC (Tue) by jmgao (subscriber, #104246) [Link] (1 responses)

> I would think that if a negative dentry hasn't been hit in the last minute you can probably toss it.

The compiler include use case is going to be pretty disconnected from any wall-clock time, since the iteration time of an edit-compile-test loop is going to be highly variable.

Positive to negative ratio

Posted Jul 7, 2026 19:10 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]

The issue with compiling is when you have to compile many individual .c files, each of which has the same set of includes. It makes sense to cache that information so you don't have to perform the same expensive file checks again for each .c file. When you get into the test and edit steps of the loop, you can safely flush the cache. It's going to be a really long time before you need to look that information up again, and the cache will repopulate as soon as you compile one file.