On Apr 14, 2025, at 11:58 AM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, 2025-04-14 at 17:14 +0100, Matthew Wilcox wrote: > [...] >>> I got that's what it's doing, and why the negative dentries are >>> useless since the file name is app specific, I'm just curious why >>> an app that knows it's the only consumer of a file places it in the >>> last place it looks rather than the first ... it seems to be >>> suboptimal and difficult for us to detect heuristically. >> >> The first two are read only. One is where the package could have an >> override, the second is where the local sysadmin could have an >> override. The third is writable. It's not entirely insane. >> >> Another way to solve this would be to notice "hey, this directory >> only has three entries and umpteen negative entries, let's do the >> thing that ramfs does to tell the dcache that it knows about all >> positive entries in this directory and delete all the negative >> ones". I forget what flag that is. > > It's not a flag, it's the dentry operations for pseudo filesystems > (simple_lookup sets simple_dentry_operations which provides a d_delete > that always says don't retain). However, that's really because all > pseudo filesystems have a complete dentry cache (all visible files have > dentries), so there's no benefit caching negative lookups (and the > d_delete trick only affects negative dentries because positive ones > have a non zero refcount). > > There is a DCACHE_DONTCACHE flag that dumps a dentry (regardless of > positive or negative) on final dput I suppose that could be set in > lookup_open() on negative under some circumstances (open flag, sysctl, > etc.). Negative dentries are only useful if there are fewer than the number of entries in that directory. If the negative dentry count exceeds the actual entry count, it would be more efficient to just cache all of the positive dentries and mark the directory with a "full dentry list" flag that indicates all of the names are already present in dcache and any miss is authoritative. In essence that gives an "infinite" negative lookup cache instead of explicitly storing all of the possible negative entries. For directories like ~/bin, /usr/bin, /usr/lib64, etc. (or any directory) where negative lookups are frequent, it should be possible to determine this threshold automatically. Once the negative dentry count exceeds the size of the directory by some factor (e.g. directory size / 16, or the actual entry count if the filesystem knows this, it doesn't have to be exactly correct) then a readdir could load all of the names to fully populate the dcache and set the "full dentry list" flag on the directory would allow dropping all negative dentries in that directory. The VFS/VM should avoid dropping directories/dentries from cache in this case, since it is saving more memory (and avoiding filesystem IO) to keep them pinned rather than dropping them from cache. There might need to be a matching "part of full dentry list" flag on the positive dentries to avoid dcache shrinking of those entries (which would invalidate the premise that the parent holds all of the possible entries in that directory), if checking the parent's flag is too expensive. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
