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.
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/