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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2022-03-31 at 12:27 -0700, Stephen Brennan wrote:
> James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> 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





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux