From: Christoph Hellwig <hch@infradead.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: 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 03:37:32 -0400 [thread overview]
Message-ID: <20101010073732.GA4097@infradead.org> (raw)
In-Reply-To: <87y6a6fsg4.fsf@basil.nowhere.org>
On Sun, Oct 10, 2010 at 08:54:51AM +0200, Andi Kleen wrote:
> That would be over 6 months just to make even a little progress.
I think that's unfair. There's been absolutely no work from Nick to
get things mergeable since 2.6.35-rc days where we gave him that
feedback. We now have had Dave pick it up and sort out various issues
with the third or so of the patchset he needed most to sort the lock
contention problems in the workloads he saw, and we'll get large
improvements for those for .37. The dcache_lock splitup alone is
another massive task that needs a lot more work, too. I've started
reviewing it and already fixed tons issues in in and the surrounding
code.
> Sorry, I am not convinced yet that any progress in this area has to be
> that glacial. Linus indicated last time he wanted to move faster on the
> VFS improvements. And the locking as it stands today is certainly a
> major problem.
>
> Maybe it's possible to come up with a way to integrate this faster?
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.
next prev parent reply other threads:[~2010-10-10 7:37 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 [this message]
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=20101010073732.GA4097@infradead.org \
--to=hch@infradead.org \
--cc=andi@firstfloor.org \
--cc=david@fromorbit.com \
--cc=fmayhar@google.com \
--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).