Re: Q: explicit alignment control for the slab allocator

[Manfred Spraul <manfred@colorfullife.com>]

Mark Hemment wrote:
> 
> > >   Hmm, no that note, seen the L1 line size defined for a Pentium IIII?
> > > 128 bytes!! (CONFIG_X86_L1_CACHE_SHIFT of 7).  That is probably going to
> > > waste a lot of space for small objects.
> > >
> > No, it doesn't:
> > HWCACHE_ALIGN means "do not cross a cache line boundary".
> 
>   Ah, I broke my code!!!!! :(
> 
>   In my original slab, the code to do "packing" of objects into a single
> cache line was #if-def'ed out for SMP to avoid the possibility of
> false-sharing between objects.  Not a large possibility, but it exists.
>
But then you need SMP_CACHE_BYTES, not L1_CACHE_BYTES.
And 128 byte aligning the 32-byte kmalloc cache wastes too much memory
;-)

If the caller of kmem_cache_create really wants do avoid false sharing
he could set align to SMP_CACHE_BYTES. (e.g. for some per-cpu data
structures)

> > Even if the hot zone is larger than the default offset, is there any advantage
> > of increasing the colour offset beyond the alignment?
> >
> > I don't see an advantage.
> 
>   I do, but like you, I don't have any data to prove my point.
>   Time to get profiling?
>

How? You've already noticed that noone in the linux kernel uses offset.

--	
	Manfred