Re: [patch] kmalloc_percpu -- 2 of 2

[Andrew Morton <akpm@digeo.com>]

Ravikiran G Thirumalai wrote:
> 
> ...
> As for the object sizes
> 1. We are assuming 32 bytes cachelines in this thread I suppose
> But ppc64 has a 128 byte cacheline and s390 a 256 byte Jumbo cacheline.
> I guess with larger cacheline sizes you have lesser no of cachelines --
> makes cachelines all the more precious.  (Right now, I am speaking
> in ignorance of the ppc64 and s390 cache architectures .. I
> can just see L1_CACHE_SHIFT in the kernel sources).  So wouldn't
> interlaced allocations help these archs .. even when you have 64
> bytes big objects?

You're assuming that the slab allocator always returns cachesize-padded
objects.  It does not have to do that.  It can return 4-byte-sized and
-aligned objects if you ask it to.

> ...
> Does this make a reasonable case for interlaced allocator now?
> (Of course, blklist init in the patch has to be modified to create
> blklists for objects of size 4, 8 .... SMP_CACHE_BYTES/2)

Oh I can see the benefits, but they appear to be rather theoretical.

I'm just applying some pressure here against adding another allocator
unless it is really needed.  On principle.

A slab cache of 4-byte objects will tend to give you what you want
anyway, due to the batch filling and freeing of the head arrays.
If that is proven to be insufficient then it would be better to
put development effort into strengthening slab, rather than competely
bypassing it.

(And a really simple solution would be to create a separate slab cache
per cpu...)