On Wed, 18 Feb 2015, Jesper Dangaard Brouer wrote: > (My use-case is in area of 32-64 elems) Ok that is in the realm of a couple of pages from the page allocator? > > 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. The problem is that going for the cache hot objects involves dealing with synchronization that you would not have to spend time on if going direct to the page allocator or going to the partial lists and retrieving multiple objects by taking a single lock. Per cpu object (cache hot!) is already optimized to the hilt. There wont be much of a benefit. -- 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>