On Wed, Jun 18, 2014 at 09:55:46AM +1000, Dave Chinner wrote:
> On Tue, Jun 03, 2014 at 02:28:49PM -0400, Brian Foster wrote:
> > It has been reported that test xfs/013 probably uses more space than
> > necessary, exhausting space if run against a several GB sized ramdisk.
> > xfs/013 primarily creates, links and removes inodes. Most of the space
> > consumption occurs via the background fsstress workload.
> > Remove the fsstress -w option that suppresses non-write operations. This
> > slightly reduces the storage footprint while still providing a
> > background workload for the test.
> > Signed-off-by: Brian Foster <bfoster@xxxxxxxxxx>
> This change makes the runtime blow out on a ramdisk from 4s to over
> ten minutes on my test machine. Non-ramdisk machines seem to be
> completely unaffected.
> I was going to say "no, bad change", but I noticed that my
> spinning disk VMs weren't affected at all. Looking more closely,
> xfs/013 is now pegging all 16 CPUs on the VM. The profile:
> - 60.73% [kernel] [k] do_raw_spin_lock
> - do_raw_spin_lock
> - 99.98% _raw_spin_lock
> - 99.83% sync_inodes_sb
> - 32.76% [kernel] [k] delay_tsc
> - delay_tsc
> - 98.43% __delay
> - _raw_spin_lock
> - 99.99% sync_inodes_sb
> OK, that's a kernel problem, not a problem with the change in the
> /me goes and dusts off his "concurrent sync scalability" patches.
Turns out the reason for this problem suddenly showing up was that I
had another (500TB) XFS filesystem mounted that had several million
clean cached inodes on it from other testing I was doing before the
xfstests run. Even so, having sync go off the deep end when there's
lots of clean cached inodes seems like a Bad Thing to me. :/