Re: [LSF/MM TOPIC] Better handling of negative dentries

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2022-03-31 at 12:27 -0700, Stephen Brennan wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> > On Tue, 2022-03-22 at 14:08 -0700, Stephen Brennan wrote:
> [snip]
> > > If we're looking at issues like [1], then the amount needs to be
> > > on a per-directory basis, and maybe roughly based on CPU speed.
> > > For other priorities or failure modes, then the policy would need
> > > to be completely different. Ideally a solution could work for
> > > almost all scenarios, but failing that, maybe it is worth
> > > allowing policy to be set by administrators via sysctl or even a
> > > BPF?
> > 
> > Looking at [1], you're really trying to contain the parent's child
> > list from exploding with negative dentries.  Looking through the
> > patch, it still strikes me that dentry_kill/retain_dentry is still
> > a better place, because if a negative dentry comes back there, it's
> > unlikely to become positive (well, fstat followed by create would
> > be the counter example, but it would partly be the app's fault for
> > not doing open(O_CREAT)).
> 
> I actually like the idea of doing the pruning during d_alloc().
> Basically, if you're creating dentries, you should also be working on
> the cache management for them.

Agreed, but all of the profligate negative dentry creators do 

lookup ... dput

The final dput causes a dentry_kill() (if there are no other
references), so they still get to work on cache management, plus you
get a better signal for "I just created a negative dentry".

I'm not saying either is right: doing it in d_alloc shares the work
among all things that create dentries which may produce better
throughput.  Doing it in dentry_kill allows you to shovel more work on
to the negative dentry creators which can cause a greater penalty for
creating them.

James