All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@suse.de>
To: john stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	lkml <linux-kernel@vger.kernel.org>,
	Clark Williams <williams@redhat.com>,
	John Kacur <jkacur@redhat.com>
Subject: Re: Nick's vfs-scalability patches ported to 2.6.33-rt
Date: Fri, 26 Feb 2010 17:01:09 +1100	[thread overview]
Message-ID: <20100226060109.GH9738@laptop> (raw)
In-Reply-To: <1267163608.2002.9.camel@work-vm>

On Thu, Feb 25, 2010 at 09:53:28PM -0800, john stultz wrote:
> Hey Thomas, Nick,
> 	I just wanted to let you know I've just finished forward porting Nick's
> patches to 2.6.33-rc8-rt2.  Luckily my forward port of Nick's patches to
> 2.6.33 applies on top of the -rt tree without any collisions, and I've
> added a handful of maybe sketchy fixups to get it working with -rt.
> 
> You can find the patchset here:
> http://sr71.net/~jstultz/dbench-scalability/patches/2.6.33-rc8-rt2/vfs-scale.33-rt.tar.bz2
> 
> Here's a chart showing how much these patches help dbench numbers on
> ramfs:
> http://sr71.net/~jstultz/dbench-scalability/graphs/2.6.33/ramfs-dbench.png
> 
> I've not done any serious stress testing with the patchset yet, but
> wanted to post it for your review.
> 
> Nick: I'd appreciate any feedback as to if any of my forward porting has
> gone awry. I'm still very green with respect to the vfs, so I don't
> doubt there are some issues hiding here.

BTW there are a few issues Al pointed out. We have to synchronize RCU
after unregistering a filesystem so d_ops/i_ops doesn't go away, and
mntput can sleep so we can't do it under RCU read lock.

The store-free path walk patches don't really have the required RCU
barriers in them either (which is fine for x86, but would have to be
fixed).


  reply	other threads:[~2010-02-26  6:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-26  5:53 Nick's vfs-scalability patches ported to 2.6.33-rt john stultz
2010-02-26  6:01 ` Nick Piggin [this message]
2010-03-03 23:31   ` john stultz
2010-03-04  3:33     ` Nick Piggin
2010-03-04  4:05       ` john stultz
2010-03-10  2:51         ` john stultz
2010-03-10  9:01           ` Christoph Hellwig
2010-03-12  3:08             ` john stultz
2010-03-12  4:41               ` Dave Chinner
2010-03-15 16:15                 ` Nick Piggin

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=20100226060109.GH9738@laptop \
    --to=npiggin@suse.de \
    --cc=jkacur@redhat.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=williams@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.