Re: [linus:master] [xfs] 9b64ca202f: fxmark.ssd_xfs_DRBH_4_bufferedio.works/sec 24.1% regression
Christoph Hellwig <[email protected]> Mon, 20 Jul 2026 09:58:01 +0200
| Newsgroups | dev.linux.lists.oe-lkp,org.kernel.vger.linux-kernel,org.kernel.vger.linux-xfs |
|---|---|
| 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.