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

[Oliver Sang <oliver.sang@intel.com>]

hi, Al Viro,

On Fri, Dec 01, 2023 at 08:04:46PM +0000, Al Viro wrote:
> 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...
>

we rerun the test and confirmed the regression still exists if comparing
20f7d1936e8a2 (viro-vfs/carved-up-__dentry_kill) step 9: fold decrment of parent's refcount into __dentry_kill()
with
b4cc0734d2574 d_prune_aliases(): use a shrink list

the data is similar to our previous report.

now we feed the results into our auto-bisect tool and hope to get results later

but due to the limitation such like auto-bisect cannot capture multi commits if
they all contribute to the regression, after we get the results from auto
bisect, we will check if any further munual efforts needed. Thanks