On Tue, Apr 16, 2019 at 06:40:06PM -0700, Darrick J. Wong wrote: > From: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > > 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@xxxxxxxxxx> 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@xxxxxxxxxxxxx
