From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/3] xfs: track delayed allocation reservations across
Date: Thu, 18 Apr 2019 07:40:31 +1000 [thread overview]
Message-ID: <20190417214031.GR29573@dread.disaster.area> (raw)
In-Reply-To: <155546520611.176278.16800498529488238281.stgit@magnolia>
On Tue, Apr 16, 2019 at 06:40:06PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
>
> Add a percpu counter to track the number of blocks directly reserved for
> delayed allocations on the data device. This counter (in contrast to
> i_delayed_blks) does not track allocated CoW staging extents or anything
> going on with the realtime device. It will be used in the upcoming
> summary counter scrub function to check the free block counts without
> having to freeze the filesystem or walk all the inodes to find the
> delayed allocations.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Hmmm. Given that a lot of modifcations to this counter are going to
be large quantities (much greater than the percpu counter batch size
of 32) this effectively just degrades to spin lock protected global
counter, yes? This is the reason we have XFS_FDBLOCKS_BATCH (1024)
for the free block percpu counter so that changes from frequent
updates via lots of smallish write()s don't need to take the global
aggregation lock very often...
So I'm guessing that this counter needs similar treatment for
scalability on large machines. If it doesn't then an atomic64_t
is all that is necessary here...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2019-04-17 21:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-17 1:40 [PATCH 0/3] xfs: scrub filesystem summary counters Darrick J. Wong
2019-04-17 1:40 ` [PATCH 1/3] xfs: track delayed allocation reservations across Darrick J. Wong
2019-04-17 21:40 ` Dave Chinner [this message]
2019-04-18 0:07 ` Darrick J. Wong
2019-04-17 1:40 ` [PATCH 2/3] xfs: allow scrubbers to pause background reclaim Darrick J. Wong
2019-04-17 21:52 ` Dave Chinner
2019-04-17 22:29 ` Darrick J. Wong
2019-04-17 22:45 ` Dave Chinner
2019-04-17 1:40 ` [PATCH 3/3] xfs: add online scrub/repair for superblock counters Darrick J. Wong
2019-04-17 22:30 ` Dave Chinner
2019-04-18 0:32 ` Darrick J. Wong
2019-04-18 23:39 ` 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=20190417214031.GR29573@dread.disaster.area \
--to=david@fromorbit.com \
--cc=darrick.wong@oracle.com \
--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