Date: Tue, 20 Apr 2004 00:24:23 -0700
From: Andrew Morton <akpm@osdl.org>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: andrea@suse.de, agruen@suse.de, linux-kernel@vger.kernel.org
Subject: Re: slab-alignment-rework.patch in -mc
Message-Id: <20040420002423.469cca01.akpm@osdl.org>
In-Reply-To: <4084017C.5080706@colorfullife.com>
References: <1082383751.6746.33.camel@f235.suse.de>
	<20040419162533.GR29954@dualathlon.random>
	<4084017C.5080706@colorfullife.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1311
Lines: 28

Manfred Spraul <manfred@colorfullife.com> wrote:
>
> > No best-guess must
>  >be made automatically by the slab code, rounding it to 16 bytes.
>  >
>  If you pass 0 as align to kmem_cache_create, then it's rounded to L2 
>  size. It's questionable if that's really the best thing - on 
>  uniprocessor, 16-byte might result is better performance - there is no 
>  risk of false sharing.

Just about every time we've cared to investigate slab alignment, we've
ended up removing SLAB_HWCACHE_ALIGN.  It seems inappropriate that _any_ of
the inode caches have this set, for example.

And this patch appears to have taken the effective size of the buffer_head
from 48 bytes up to 64, which hurts.

So I do think that we should either make "align=0" translate to "pack them
densely" or do the big sweep across all kmem_cache_create() callsites.

If the latter, while we're there, let's remove SLAB_HWCACHE_ALIGN where it
isn't obviously appropriate.  I'd imagine that being able to fit more inodes
into memory is a net win over the occasional sharing effect, for example.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/