public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: aalbersh@kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/2] mkfs: enable new features by default
Date: Thu, 4 Dec 2025 10:48:05 -0800	[thread overview]
Message-ID: <20251204184805.GK89472@frogsfrogsfrogs> (raw)
In-Reply-To: <aS_ZOpzcp04ovBwk@infradead.org>

On Tue, Dec 02, 2025 at 10:31:22PM -0800, Christoph Hellwig wrote:
> On Tue, Dec 02, 2025 at 04:53:45PM -0800, Darrick J. Wong wrote:
> > On Mon, Dec 01, 2025 at 11:38:46PM -0800, Christoph Hellwig wrote:
> > > On Mon, Dec 01, 2025 at 05:28:16PM -0800, Darrick J. Wong wrote:
> > > > From: Darrick J. Wong <djwong@kernel.org>
> > > > 
> > > > Since the LTS is coming up, enable parent pointers and exchange-range by
> > > > default for all users.  Also fix up an out of date comment.
> > > 
> > > Do you have any numbers that show the overhead or non-overhead of
> > > enabling rmap?  It will increase the amount of metadata written quite
> > > a bit.
> > 
> > I'm assuming you're interested in the overhead of *parent pointers* and
> > not rmap since we turned on rmap by default back in 2023?
> 
> Yes, sorry.
> 
> > I see more or less the same timings for the nine subsequent runs for
> > each parent= setting.  I think it's safe to say the overhead ranges
> > between negligible and 10% on a cold new filesystem.
> 
> Should we document this cleary?  Because this means at least some
> workloads are going to see a performance decrease.

Yep.  But first -- all those results are inaccurate because I forgot
that fsstress quietly ignores everything after the first op=freq
component of the optarg, so all that benchmark was doing was creating
millions of files in a single directory and never deleting anything.
That's why the subsequent runs were much faster -- most of those files
were already created.

So I'll send a patch to fstests to fix that behavior.  With that, the
benchmark that I alleged I was running produces these numbers when
creating a directory tree of only empty files:

naming   =version 2              bsize=4096   ascii-ci=0, ftype=1, parent=1
real    0m12.742s
user    0m28.074s
sys     0m10.839s

real    0m13.469s
user    0m25.827s
sys     0m11.816s

real    0m11.352s
user    0m22.602s
sys     0m11.275s

naming   =version 2              bsize=4096   ascii-ci=0, ftype=1, parent=0
real    0m12.782s
user    0m28.892s
sys     0m8.897s

real    0m13.591s
user    0m25.371s
sys     0m9.601s

real    0m10.012s
user    0m20.849s
sys     0m9.018s

Almost no difference here!  If I add in write=1 then there's a 5%
decrease going to parent=1:

naming   =version 2              bsize=4096   ascii-ci=0, ftype=1, parent=1
real    0m15.020s
user    0m22.358s
sys     0m14.827s

real    0m17.196s
user    0m22.888s
sys     0m15.586s

real    0m16.668s
user    0m21.709s
sys     0m15.425s

naming   =version 2              bsize=4096   ascii-ci=0, ftype=1, parent=0
real    0m14.808s
user    0m22.266s
sys     0m12.843s

real    0m16.323s
user    0m22.409s
sys     0m13.695s

real    0m15.562s
user    0m21.740s
sys     0m12.927s

--D

  reply	other threads:[~2025-12-04 18:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-02  1:27 [PATCHSET 2/2] xfsprogs: enable new stable features for 6.18 Darrick J. Wong
2025-12-02  1:28 ` [PATCH 1/2] mkfs: enable new features by default Darrick J. Wong
2025-12-02  7:38   ` Christoph Hellwig
2025-12-03  0:53     ` Darrick J. Wong
2025-12-03  6:31       ` Christoph Hellwig
2025-12-04 18:48         ` Darrick J. Wong [this message]
2025-12-02  1:28 ` [PATCH 2/2] mkfs: add 2025 LTS config file Darrick J. Wong
  -- strict thread matches above, loose matches on Subject: below --
2025-12-09 16:16 [PATCHSET V2] xfsprogs: enable new stable features for 6.18 Darrick J. Wong
2025-12-09 16:16 ` [PATCH 1/2] mkfs: enable new features by default Darrick J. Wong
2025-12-09 16:22   ` Christoph Hellwig
2025-12-09 22:25   ` Dave Chinner
2025-12-10 23:49     ` Darrick J. Wong
2025-12-15 23:59       ` Dave Chinner
2025-12-16 23:07         ` Darrick J. Wong

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=20251204184805.GK89472@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=aalbersh@kernel.org \
    --cc=hch@infradead.org \
    --cc=linux-xfs@vger.kernel.org \
    /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