linux-kernel - Re: [linus:master] [btrfs] b7fdfd29a1: postmark.transactions 9.5% regression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251031192048.GK13846@twin.jikos.cz>
Date: Fri, 31 Oct 2025 20:20:48 +0100
From: David Sterba <dsterba@...e.cz>
To: Qu Wenruo <quwenruo.btrfs@....com>
Cc: kernel test robot <oliver.sang@...el.com>, Qu Wenruo <wqu@...e.com>,
	oe-lkp@...ts.linux.dev, lkp@...el.com, linux-kernel@...r.kernel.org,
	David Sterba <dsterba@...e.com>, HAN Yuwei <hrx@...t.moe>,
	linux-btrfs@...r.kernel.org
Subject: Re: [linus:master] [btrfs] b7fdfd29a1: postmark.transactions 9.5%
 regression

On Mon, Oct 27, 2025 at 06:19:59PM +1030, Qu Wenruo wrote:
> 在 2025/10/27 18:11, kernel test robot 写道:
> > Hello,
> > 
> > kernel test robot noticed a 9.5% regression of postmark.transactions on:
> > 
> > 
> > commit: b7fdfd29a136a17c5c8ad9e9bbf89c48919c3d19 ("btrfs: only set the device specific options after devices are opened")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> > 
> > 
> > we are in fact not sure what's the connection between this change and the
> > postmark.transactions performance. still report out due to below checks.
> > 
> > [still regression on      linus/master 4bb1f7e19c4a1d6eeb52b80acff5ac63edd1b91d]
> > [regression chould be solved by reverting this commit on linus/master head]
> > [still regression on linux-next/master 72fb0170ef1f45addf726319c52a0562b6913707]
> > 
> > testcase: postmark
> > config: x86_64-rhel-9.4
> > compiler: gcc-14
> > test machine: 224 threads 4 sockets Intel(R) Xeon(R) Platinum 8380H CPU @ 2.90GHz (Cooper Lake) with 192G memory
> > parameters:
> > 
> > 	disk: 1HDD
> > 	fs: btrfs
> > 	fs1: nfsv4
> > 	number: 4000n
> > 	trans: 10000s
> > 	subdirs: 100d
> > 	cpufreq_governor: performance
> > 
> > 
> > 
> > 
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <oliver.sang@...el.com>
> > | Closes: https://lore.kernel.org/oe-lkp/202510271449.efa21738-lkp@intel.com
> > 
> > 
> > Details are as below:
> > -------------------------------------------------------------------------------------------------->
> > 
> > 
> > The kernel config and materials to reproduce are available at:
> > https://download.01.org/0day-ci/archive/20251027/202510271449.efa21738-lkp@intel.com
> > 
> > =========================================================================================
> > compiler/cpufreq_governor/disk/fs1/fs/kconfig/number/rootfs/subdirs/tbox_group/testcase/trans:
> >    gcc-14/performance/1HDD/nfsv4/btrfs/x86_64-rhel-9.4/4000n/debian-13-x86_64-20250902.cgz/100d/lkp-cpl-4sp2/postmark/10000s
> > 
> > commit:
> >    53a4acbfc1 ("btrfs: fix memory leak on duplicated memory in the qgroup assign ioctl")
> 
> This is definitely not related.
> 
> >    b7fdfd29a1 ("btrfs: only set the device specific options after devices are opened")
> 
> But this may affect performance, because without this fix, btrfs always 
> falls back to `ssd` mount option
> 
> Now it will properly detect rotating devices, and won't set `ssd` mount 
> option by default.
> 
> But if this is causing performance drop, we should really consider if 
> `ssd` should be the only mode we support.

I think it's a good idea, though this can have also negative performance
impact.

The SSD optimizations are now only the cluster size selection
(fetch_cluster_info) and waiting for log writers (btrfs_sync_log(),
added in 2011 cd354ad613a39). IIRC there used to be selection for the
async io.  On rotational devices the extent placement can have impact on
seeking, but this becomes upredictable on aged filesystems.