On Mon, Dec 29, 2008 at 03:00:37PM -0800, Dave Hansen wrote:
> 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.
Still results in cacheline contention, however...
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
