From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: fstests@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH] xfs/013: allow non-write fsstress operations in background workload
Date: Wed, 18 Jun 2014 11:22:23 +1000 [thread overview]
Message-ID: <20140618012223.GB4453@dastard> (raw)
In-Reply-To: <20140617235546.GY4453@dastard>
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@redhat.com>
>
> 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
> sync_inodes_one_sb
> iterate_supers
> sys_sync
> tracesys
> sync
> - 32.76% [kernel] [k] delay_tsc
> - delay_tsc
> - 98.43% __delay
> do_raw_spin_lock
> - _raw_spin_lock
> - 99.99% sync_inodes_sb
> sync_inodes_one_sb
> iterate_supers
> sys_sync
> tracesys
> sync
>
> OK, that's a kernel problem, not a problem with the change in the
> test...
>
> /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. :/
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2014-06-18 1:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-03 18:28 [PATCH] xfs/013: allow non-write fsstress operations in background workload Brian Foster
2014-06-17 23:55 ` Dave Chinner
2014-06-18 1:22 ` Dave Chinner [this message]
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=20140618012223.GB4453@dastard \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=fstests@vger.kernel.org \
--cc=xfs@oss.sgi.com \
/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