Re: Q: explicit alignment control for the slab allocator

[Mark Hemment]

On Thu, 1 Mar 2001, Manfred Spraul wrote:
> Yes, I see the difference, but I'm not sure that it will work as
> intended.
> offset must be a multiple of the alignment, everything else won't work.

  The code does force the offset to be a multiple of the alignment -
rounding the offset up.  The idea was to a caller could something like;
	kmem_cache_create("foo", sizeof(foo_s),
			  offsetoff(foo_s, member), ....);

where structure members in foo_s are "hot" up until the 'member'
structure.

> In which cases an offset > alignment is really a win?

  You've got me. :)  I don't know.
  In the Bonwick paper, such a facility was described, so I thought "hey,
sounds like that might be useful".
  Could be a win on archs with small L1 cache line sizes (16bytes on a
486) - but most modern processors have larger lines.
  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.

> Obviously using offset 32 bytes for a structure with a 64 byte hot zone
> means that 2 slabs with a different "color" compete for the same cache
> lines [just assuming 32 byte cache lines for simplicity] in 50% of the
> cases, but otoh offset==64 halfs the number of possible colors.

  Yes.
  It is possibly to improve on the current slab allocator, to get an
extra colour or two out of it for some object sizes (eg. when the slab
management is on slab, it is only ever at the front of a slab - it could
also wrap round to the rear).

Mark