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
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
- 99.98% _raw_spin_lock
- 99.83% sync_inodes_sb
- 32.76% [kernel] [k] delay_tsc
- 98.43% __delay
- 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.