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
