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 http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>