From: Andi Kleen <andi@firstfloor.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Andi Kleen <andi@firstfloor.org>,
Dave Chinner <david@fromorbit.com>,
Frank Mayhar <fmayhar@google.com>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
mrubin@google.com, torvalds@linux-foundation.org,
viro@zeniv.linux.org.uk
Subject: Re: Results of my VFS scaling evaluation.
Date: Sun, 10 Oct 2010 14:03:09 +0200 [thread overview]
Message-ID: <20101010120309.GB8256@basil.fritz.box> (raw)
In-Reply-To: <20101010083749.GA8702@infradead.org>
On Sun, Oct 10, 2010 at 04:37:49AM -0400, Christoph Hellwig wrote:
> On Sun, Oct 10, 2010 at 10:20:39AM +0200, Andi Kleen wrote:
> > > Certainly not for .37, where even the inode_lock splitup is pretty damn
> > > later. Nick disappearing for a few weeks and others having to pick up
> > > the work to sort it out certainly doesn't help. And the dcache_lock
> > > splitup is a much larget task than that anyway. Getting that into .38
> > > is the enabler for doing more fancy things. And as Dave mentioned at
> > > least in the writeback area it's much better to sort out the algorithmic
> > > problems now than to blindly split some locks up more.
> >
> > I don't see why the algorithmic work can't be done in parallel
> > to the lock split up?
> >
> > Just the lock split up on its own gives us large gains here.
>
> What about actually starting to test the stuff headed towards Al's tree
> to verify your assumptions? It's nice to have a lot of people talking,
That's in the works. Previously all testing work was done
on Nick's patch series.
> but actually helping with review and testing would be more useful.
Well the constant refactoring is certainly not helping with testing.
Also what typically happens is that if we don't fix all the serious
VFS locking issues (like Nick's patch kit) we just move from one bottle
neck to another.
> Yes, lots of things could be done in parallel, but it needs people to
> actually work on it. And right now that's mostly Dave for the real
> work, with me trying to prepare a proper dcache series for .38, and Al
> doing some review.
It was not clear to me what was so horrible with Nick's original
patchkit? Sure there were a few rough edges, but does it really
need to be fully redone?
It certainly held up great to lots of testing, both at our side
and apparently Google's too.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
next prev parent reply other threads:[~2010-10-10 12:03 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
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 [this message]
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=20101010120309.GB8256@basil.fritz.box \
--to=andi@firstfloor.org \
--cc=david@fromorbit.com \
--cc=fmayhar@google.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mrubin@google.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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).