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

Christoph Hellwig <[email protected]>
Newsgroups org.kernel.vger.linux-xfs,dev.linux.lists.oe-lkp,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.