From: Dave Chinner <david@fromorbit.com>
To: Frank Mayhar <fmayhar@google.com>
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, mrubin@google.com
Subject: Re: Results of my VFS scaling evaluation.
Date: Sat, 9 Oct 2010 14:16:09 +1100 [thread overview]
Message-ID: <20101009031609.GK4681@dastard> (raw)
In-Reply-To: <1286580739.3153.57.camel@bobble.smo.corp.google.com>
On Fri, Oct 08, 2010 at 04:32:19PM -0700, Frank Mayhar wrote:
> Nick Piggin has been doing work on lock contention in VFS, in particular
> to remove the dcache and inode locks, and we are very interested in this
> work. He has entirely eliminated two of the most contended locks,
> replacing them with a combination of more granular locking, seqlocks,
> RCU lists and other mechanisms that reduce locking and contention in
> general. He has published this work at
>
> git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git
While the code in that tree might be stable, it's not really in any
shape acceptible for mainline inclusion.
I've been reworking the inode_lock breakup code from this patch set,
and there is significant change in the locking order and structure
compared to the above tree to avoid the unmaintainable mess of
trylock operations that Nick's patchset ended up with.
Also, breaking the series down into smaller bunches also shows that
certain optimisations made later in the series (e.g. making
writeback lists per CPU, breaking up inode LRUs, etc) do not deal
with the primary causes of observable contention (e.g. unbound
writeback parallelism in balance_dirty_pages), so the parts of the
original patch set might not even end up in mainline for some time...
FWIW, it would be good if this sort of testing could be run on the tree
under review here:
git://git.kernel.org/pub/scm/linux/kernel/git/dgc/xfsdev.git inode-scale
This is what I'm trying to get reviewed in time for a .37 merge. If
that gets in .37, then I'll probably follow the same process for the
dcache_lock in .38, and after that we can then consider all the RCU
changes for both the inode and dentry operations.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2010-10-09 3:16 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-08 23:32 Results of my VFS scaling evaluation Frank Mayhar
2010-10-09 0:33 ` Frank Mayhar
2010-10-09 0:38 ` Valerie Aurora
2010-10-11 18:47 ` Frank Mayhar
2011-01-13 11:13 ` Nick Piggin
2010-10-09 3:16 ` Dave Chinner [this message]
2010-10-10 6:54 ` Andi Kleen
2010-10-10 7:37 ` Christoph Hellwig
2010-10-10 8:20 ` Andi Kleen
2010-10-10 8:37 ` Christoph Hellwig
2010-10-10 12:03 ` Andi Kleen
2010-10-10 23:50 ` Dave Chinner
2010-10-10 23:31 ` Dave Chinner
2010-10-10 6:50 ` Andi Kleen
2010-10-19 21:59 ` Results of my VFS scaling evaluation, redux Frank Mayhar
2010-10-19 22:03 ` Frank Mayhar
2010-10-22 19:03 ` VFS scaling evaluation results, redux Frank Mayhar
2010-10-23 0:00 ` Lin Ming
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=20101009031609.GK4681@dastard \
--to=david@fromorbit.com \
--cc=fmayhar@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mrubin@google.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;
as well as URLs for NNTP newsgroup(s).