All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.