Messages in this thread | | | Date | Fri, 02 Mar 2001 14:22:06 +0100 | From | Manfred Spraul <> | Subject | Re: Q: explicit alignment control for the slab allocator |
| |
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 - 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/
| |