On Mon, Dec 04, 2023 at 09:37:45PM +0800, Oliver Sang wrote: > > 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 Thank you. > 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 My apologies for the number of steps in that ;-/ FWIW, what I'm really afraid of is this regression coming from #4; it might mean that on some loads shrink_dcache_parent() benefits from evicting a parent while it still has children halfway through ->d_iput(). That should not happen to sillyrenamed children, which is the only case where the mainline instances of ->d_iput() currently access the parent, but that depends upon too many subtle details spread over too many places ;-/ Oh, well - let's see what profiles show... I still hope that it's not where the trouble comes from - it would've lead the extra cycles in shrink_dcache_parent() or d_walk() called from it and profiles you've posted do not show that, so...
