All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: npiggin@suse.de, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [patch 1/2] fs: mnt_want_write speedup
Date: Thu, 2 Apr 2009 11:08:24 -0700	[thread overview]
Message-ID: <20090402110824.e0c1ec72.akpm@linux-foundation.org> (raw)
In-Reply-To: <1236809477.30142.83.camel@nimitz>

On Wed, 11 Mar 2009 15:11:17 -0700
Dave Hansen <dave@linux.vnet.ibm.com> wrote:

> I'm feeling a bit better about these, although I am still honestly quite
> afraid of the barriers.  I also didn't like all the #ifdefs much, but
> here's some help on that.

Do we need the ifdefs at all?

> How about this on top of what you have as a bit of a cleanup?  It gets
> rid of all the new #ifdefs in .c files?
> 
> Did I miss the use of get_mnt_writers_ptr()?  I don't think I actually
> saw it used anywhere in this pair of patches, so I've stolen it.  I
> think gcc should compile all this new stuff down to be basically the
> same as you had before.  The one thing I'm not horribly sure of is the
> "out_free_devname:" label.  It shouldn't be reachable in the !SMP case. 
> 
> I could also consolidate the header #ifdefs into a single one if you
> think that looks better.
> 
> This is just compile tested, btw.  
> 
> ---
> 
>  linux-2.6.git-dave/fs/namespace.c        |   35 ++++++-------------------------
>  linux-2.6.git-dave/include/linux/mount.h |   30 ++++++++++++++++++++++++--
>  2 files changed, 35 insertions(+), 30 deletions(-)
> 
> diff -puN include/linux/mount.h~move-ifdefs-take2 include/linux/mount.h
> --- linux-2.6.git/include/linux/mount.h~move-ifdefs-take2	2009-03-11 15:01:10.000000000 -0700
> +++ linux-2.6.git-dave/include/linux/mount.h	2009-03-11 15:02:01.000000000 -0700
> @@ -71,15 +71,41 @@ struct vfsmount {
>  #endif
>  };
>  
> -static inline int *get_mnt_writers_ptr(struct vfsmount *mnt)
> +static inline int *get_mnt_writers_ptr_cpu(struct vfsmount *mnt,
> +					   int cpu)
>  {
>  #ifdef CONFIG_SMP
> -	return mnt->mnt_writers;
> +	return per_cpu_ptr(mnt->mnt_writers, cpu);
>  #else
>  	return &mnt->mnt_writers;
>  #endif
>  }
>  
> +static inline int *get_mnt_writers_ptr(struct vfsmount *mnt)
> +{
> +	return get_mnt_writers_ptr_cpu(mnt, smp_processor_id());
> +}
> +
> +static inline int alloc_mnt_writers(struct vfsmount *mnt)
> +{
> +#ifdef CONFIG_SMP
> +	mnt->mnt_writers = alloc_percpu(int);
> +	if (!mnt->mnt_writers)
> +		return -ENOMEM;
> +#else
> +	mnt->mnt_writers = 0;
> +#endif
> +	return 0;
> +}

If the CONFIG_SMP=n code is just removed, the percpu code should dtrt
with CONFIG_SMP=n.  There is the additional pointer indirection though,
I guess.  Do we do it often enough to be concerned about the cost?



      parent reply	other threads:[~2009-04-02 18:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-10 14:37 [patch 1/2] fs: mnt_want_write speedup Nick Piggin
2009-03-10 14:38 ` [patch 2/2] fs: introduce mnt_clone_write Nick Piggin
2009-03-10 14:55   ` Matthew Wilcox
2009-03-10 15:08     ` Nick Piggin
2009-03-10 14:48 ` [patch 1/2] fs: mnt_want_write speedup Matthew Wilcox
2009-03-10 15:03   ` Nick Piggin
2009-03-10 15:31 ` Nick Piggin
2009-03-11 22:11 ` Dave Hansen
2009-03-12  4:13   ` Nick Piggin
2009-03-18 19:13     ` Dave Hansen
2009-04-02 18:22       ` Nick Piggin
2009-04-02 18:37         ` Dave Hansen
2009-04-02 20:31           ` Christoph Hellwig
2009-04-03  1:29           ` Nick Piggin
2009-04-02 18:43         ` Al Viro
2009-04-02 18:48           ` Al Viro
2009-04-02 19:08           ` Dave Hansen
2009-04-03 10:31             ` Al Viro
2009-04-03  1:31           ` Nick Piggin
2009-04-02 18:08   ` Andrew Morton [this message]

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=20090402110824.e0c1ec72.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=dave@linux.vnet.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@suse.de \
    /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.