From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: kernel test robot <oliver.sang@intel.com>,
Qu Wenruo <wqu@suse.com>,
oe-lkp@lists.linux.dev, lkp@intel.com,
linux-kernel@vger.kernel.org, David Sterba <dsterba@suse.com>,
HAN Yuwei <hrx@bupt.moe>,
linux-btrfs@vger.kernel.org
Subject: Re: [linus:master] [btrfs] b7fdfd29a1: postmark.transactions 9.5% regression
Date: Fri, 31 Oct 2025 20:20:48 +0100 [thread overview]
Message-ID: <20251031192048.GK13846@twin.jikos.cz> (raw)
In-Reply-To: <2adac975-01f1-4640-a073-715c804987d6@gmx.com>
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@intel.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.
prev parent reply other threads:[~2025-10-31 19:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-27 7:41 kernel test robot
2025-10-27 7:49 ` Qu Wenruo
2025-10-28 5:14 ` Oliver Sang
2025-10-31 19:20 ` David Sterba [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251031192048.GK13846@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=dsterba@suse.com \
--cc=hrx@bupt.moe \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=quwenruo.btrfs@gmx.com \
--cc=wqu@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®