mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.

      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®