From: Dave Hansen <dave@linux.vnet.ibm.com>
Subject: Re: [rfc][patch 1/2] mnt_want_write speedup 1
Date: Mon, 29 Dec 2008 15:00:37 -0800
Message-ID: <1230591637.19452.129.camel@nimitz>
References: <20081219061937.GA16268@wotan.suse.de>
	 <1229669697.17206.602.camel@nimitz> <20081219070311.GA26419@wotan.suse.de>
	 <1229700721.17206.634.camel@nimitz>  <20081222043526.GC13406@wotan.suse.de>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Cc: Linux Memory Management List <linux-mm@kvack.org>,
	linux-fsdevel@vger.kernel.org
To: Nick Piggin <npiggin@suse.de>
In-Reply-To: <20081222043526.GC13406@wotan.suse.de>
Sender: linux-fsdevel-owner@vger.kernel.org

On Mon, 2008-12-22 at 05:35 +0100, Nick Piggin wrote:
> > Is there a real good reason to allocate the percpu counters dynamically?
> > Might as well stick them in the vfsmount and let the one
> > kmem_cache_zalloc() in alloc_vfsmnt() do a bit larger of an allocation.
> > Did you think that was going to bloat it to a compound allocation or
> > something?  I hate the #ifdefs. :)
> 
> Distros want to ship big NR_CPUS kernels and have them run reasonably on
> small num_possible_cpus() systems. But also, it would help to avoid
> cacheline bouncing from false sharing (allocpercpu.c code can also mess
> this bug for small objects like these counters, but that's a problem
> with the allocpercpu code which should be fixed anyway).

I guess we could also play the old trick:

struct vfsmount
{
	...
	int mnt_writers[0];
};

And just 

void __init mnt_init(void)
{
...
	int size = sizeof(struct vfsmount) + num_possible_cpus() * sizeof(int)

-       mnt_cache = kmem_cache_create("mnt_cache", sizeof(struct vfsmount),
+       mnt_cache = kmem_cache_create("mnt_cache", size,
                        0, SLAB_HWCACHE_ALIGN | SLAB_PANIC, NULL);

That should save us the dereference from the pointer and still let it be
pretty flexible.  

-- Dave