From: Dave Chinner <david@fromorbit.com>
To: xfs@oss.sgi.com
Subject: [PATCH 0/5] xfs_repair: scalability inmprovements
Date: Thu, 12 Dec 2013 18:22:20 +1100 [thread overview]
Message-ID: <1386832945-19763-1-git-send-email-david@fromorbit.com> (raw)
HI folks,
The following 5 patches to xfs_repair improve scalability on high
IOPS devices. They remove contention points that limit the number of
IO threads that we can use, whilst also protecting against using too
much concurrency.
The first patch removes a contention point in a 3rd party
translation library by avoiding translating static data repeatedly.
The second separates the per-ag locks into separate cachelines, so
we don't get threads working on different AGs contending on
cachelines shared by non-shared locks.
THe third parallelises phase 6, which was never done because the
original repair parallelism work didn't show it to be a significant
contributor to runtime. Even serialised it was as fast as the
parallelised phases. However, that's a different story now with SSDs
- it's the only phase that is CPU bound because it doesn't spread
the work across multiple CPUs, and so is by far the slowest phase of
repair on SSDs.
The fourht patch corrects a problem with CPU usage in the buffer
cache - the hash table distributions are awful.
Finally, the last patch fixes a problem reported by Michael Semon
where too much concurrency was being used by xfs_repair and hence
failing because it was unable to allocate threads.
Cheers,
Dave.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next reply other threads:[~2013-12-12 7:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-12 7:22 Dave Chinner [this message]
2013-12-12 7:22 ` [PATCH 1/5] repair: translation lookups limit scalability Dave Chinner
2013-12-12 18:26 ` Christoph Hellwig
2013-12-12 18:58 ` Brian Foster
2013-12-12 7:22 ` [PATCH 2/5] repair: per AG locks contend for cachelines Dave Chinner
2013-12-12 18:27 ` Christoph Hellwig
2013-12-12 18:58 ` Brian Foster
2013-12-12 20:46 ` Dave Chinner
2013-12-12 7:22 ` [PATCH 3/5] repair: phase 6 is trivially parallelisable Dave Chinner
2013-12-12 18:43 ` Christoph Hellwig
2013-12-12 20:53 ` Dave Chinner
2013-12-12 18:59 ` Brian Foster
2013-12-12 7:22 ` [PATCH 4/5] libxfs: buffer cache hashing is suboptimal Dave Chinner
2013-12-12 18:28 ` Christoph Hellwig
2013-12-12 18:59 ` Brian Foster
2013-12-12 20:56 ` Dave Chinner
2013-12-13 14:23 ` Brian Foster
2013-12-12 7:22 ` [PATCH 5/5] repair: limit auto-striding concurrency apprpriately Dave Chinner
2013-12-12 18:29 ` Christoph Hellwig
2013-12-12 21:00 ` Dave Chinner
2013-12-12 18:59 ` Brian Foster
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=1386832945-19763-1-git-send-email-david@fromorbit.com \
--to=david@fromorbit.com \
--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