Re: [PATCH 1/3] Slab infrastructure for array operations

From: Jesper Dangaard Brouer
Date: Tue Feb 17 2015 - 16:33:08 EST

On Tue, 17 Feb 2015 10:03:51 -0600 (CST)
Christoph Lameter <cl@xxxxxxxxx> wrote:

> On Tue, 17 Feb 2015, Joonsoo Kim wrote:
> > If we allocate objects from local cache as much as possible, we can
> > keep temporal locality and return objects as fast as possible since
> > returing objects from local cache just needs memcpy from local array
> > cache to destination array.
> I thought the point was that this is used to allocate very large amounts
> of objects. The hotness is not that big of an issue.

(My use-case is in area of 32-64 elems)

> Its not that detailed. It is just layin out the basic strategy for the
> array allocs. First go to the partial lists to decrease fragmentation.
> Then bypass the allocator layers completely and go direct to the page
> allocator if all objects that the page will accomodate can be put into
> the array. Lastly use the cpu hot objects to fill in the leftover (which
> would in any case be less than the objects in a page).

IMHO this strategy is a bit off, from what I was looking for.

I would prefer the first elements to be cache hot, and the later/rest of
the elements can be more cache-cold. Reasoning behind this is,
subsystem calling this alloc_array have likely ran out of elems (from
it's local store/prev-call) and need to handout one elem immediately
after this call returns.

Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at