linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	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: Mon, 11 Oct 2010 10:50:39 +1100	[thread overview]
Message-ID: <20101010235039.GP4681@dastard> (raw)
In-Reply-To: <20101010120309.GB8256@basil.fritz.box>

On Sun, Oct 10, 2010 at 02:03:09PM +0200, Andi Kleen wrote:
> On Sun, Oct 10, 2010 at 04:37:49AM -0400, Christoph Hellwig wrote:
> > but actually helping with review and testing would be more useful.
> 
> Well the constant refactoring is certainly not helping with testing.

That is the way of review cycles. The need for significant
refactoring and reworking shows how much work the VFS maintainers
consider still needs to be done on the patch set.

> 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.

Sure, but at least there is a plan for dealing with them all and,
most importantly, people committed to pushing it forward.

Fundamentally, we need to understand the source of the lock
contention problems before trying to fix them. Nick just hit them
repeatedly with a big hammer until they went away....

> > 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?

I think the trylock mess is pretty much universally disliked by
anyone who looks at the VFS and writeback code on a daily basis. And
IMO the level of nested trylock looping is generally indicative of
getting the lock ordering strategy wrong in the first place.

Not to mention that as soon as I tried to re-order cleanups to the
front of the queue, it was pretty clear that it was going to be
unmaintainable, too.

> It certainly held up great to lots of testing, both at our side
> and apparently Google's too.

Not the least bit relevant, IMO, when the code ends up unmaintanable
in the long term.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-10-10 23:50 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
2010-10-10 23:50             ` Dave Chinner [this message]
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=20101010235039.GP4681@dastard \
    --to=david@fromorbit.com \
    --cc=andi@firstfloor.org \
    --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).