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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/