Re: [viro-vfs:work.dcache2] [__dentry_kill()] 1b738f196e: stress-ng.sysinfo.ops_per_sec -27.2% regression

[Al Viro <viro@zeniv.linux.org.uk>]

On Fri, Dec 01, 2023 at 06:56:03AM +0000, Al Viro wrote:
> On Fri, Dec 01, 2023 at 04:09:51AM +0000, Al Viro wrote:
> > On Fri, Dec 01, 2023 at 10:13:09AM +0800, Oliver Sang wrote:
> > 
> > > > Very interesting...  Out of curiosity, what effect would the following
> > > > have on top of 1b738f196e?
> > > 
> > > I applied the patch upon 1b738f196e (as below fec356fd0c), but seems less
> > > useful.
> > 
> > I would be rather surprised if it fixed anything; it's just that 1b738f196e
> > changes two things - locking rules for __dentry_kill() and, in some cases,
> > the order of dentry eviction in shrink_dentry_list().  That delta on top of
> > it restores the original order in shrink_dentry_list(), leaving pretty much
> > the changes in lock_for_kill()/dput()/__dentry_kill().
> > 
> > Interesting...  Looks like there are serious changes in context switch
> > frequencies, but I don't see where could that have come from...
> 
> In principle it could be an effect of enforcing the ordering between __dentry_kill()
> of child and parent, but if that's what is going on... we would've seen
> more iterations of loop in shrink_dcache_parent() and/or d_walk() calls in
> it having more work to do.  But... had that been what's going on, wouldn't we
> see some of those functions in the changed part of profile?  
> 
> I'll try to split that thing into a series of steps, so we could at least narrow
> the effect down, but that'll have to wait until tomorrow ;-/

OK, a carved-up series (on top of 1b738f196e^) is in #carved-up-__dentry_kill
That's 9 commits, leading to something close to 1b738f196e+patch you've tested
yesterday; could you profile them on your reproducers?  That might give some
useful information about the nature of the regression...