Re: [PATCH 09/11] generic/778: fix severe performance problems

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Oct 21, 2025 at 09:20:55PM -0700, Christoph Hellwig wrote:
> On Tue, Oct 21, 2025 at 11:41:33AM -0700, Darrick J. Wong wrote:
> > As a result, one loop through the test takes almost 4 minutes.  The test
> > loops 20 times, so it runs for 80 minutes(!!) which is a really long
> > time.
> 
> Heh.  I'm glade none of my usual test setups even supports atomics I
> guess :)

FWIW the failure was on a regular xfs, no hw atomics.  So in theory
you're affected, but only if you pulled the 20 Oct next branch.

> > So the first thing we do is observe that the giant slow loop is being
> > run as a single thread on an empty filesystem.  Most of the time the
> > allocator generates a mostly physically contiguous file.  We could
> > fallocate the whole file instead of fallocating one block every other
> > time through the loop.  This halves the setup time.
> > 
> > Next, we can also stuff the remaining pwrite commands into a bash array
> > and only invoke xfs_io once every 128x through the loop.  This amortizes
> > the xfs_io startup time, which reduces the test loop runtime to about 20
> > seconds.
> 
> Wouldn't it make sense to adopt src/punch-alternating.c to also be
> able to create unwritten extents instead of holes for the punched
> range and run all of this from a C program?

For the write sizes it comes up with I'm guessing that this test will
almost always be poking the software fallbacks so it probably doesn't
matter if the file is full of holes.

> Otherwise this looks good:
> 
> Reviewed-by: Christoph Hellwig <hch@lst.de>

Thanks!

--D