Re: [linus:master] [xfs] 9b64ca202f: fxmark.ssd_xfs_DRBH_4_bufferedio.works/sec 24.1% regression
From: Christoph Hellwig
Date: Mon Jul 20 2026 - 03:58:18 EST
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.