Re: [linus:master] [xfs] 9b64ca202f: fxmark.ssd_xfs_DRBH_4_bufferedio.works/sec 24.1% regression

[Christoph Hellwig <hch@lst.de>]

On Sun, Jul 19, 2026 at 04:16:14PM +0800, Oliver Sang wrote:
> hi, Christoph Hellwig,
> 
> On Fri, Jul 17, 2026 at 08:48:07AM +0200, Christoph Hellwig wrote:
> > On Thu, Jul 16, 2026 at 09:13:19PM +0800, kernel test robot wrote:
> > > 
> > > 
> > > Hello,
> > > 
> > > kernel test robot noticed a 24.1% regression of fxmark.ssd_xfs_DRBH_4_bufferedio.works/sec on:
> > > 
> > 
> > This looks really odd.  While the patch adds a bit more computation,
> > that is very cheap shifting and masking.  
> 
> in order to avoid the false positive, we rebuilt the kernel and rerun tests
> on both 9b64ca202f and its parent. though the data has some differences with
> last time, the regression trend is still similar - 21.8% regression this time.
> 
> 
> > So the only theory I have here
> > is that this somehow affects the inode data layout.  Can you re-run this
> > with the patch below applied on top of commit
> > 9b64ca202f364a6bf8e19bdd20953bc2d776c67f ?
> 
> yeah, but applying your patch upon 9b64ca202f, we saw the regression recovered.
> 
> from average data, it now becomes even little better than the parent of
> 9b64ca202f, i.e. caffb4252c, but since the data is not very stable - 4% stddev
> for caffb4252c and 6% stddev for bd79e961ea, we cannot call +3.1% a valid
> improvement according to our bot's rules.

Already, so this must be something about cache line sharing.  I'll try to get
hold of a big enough test box to see if I can reproduce this, in the worst
case we'll have to just add back the padding for now.