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

2015-02-18 Thread Christoph Lameter
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 decreas

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

2015-02-17 Thread Jesper Dangaard Brouer
On Tue, 17 Feb 2015 10:03:51 -0600 (CST) Christoph Lameter 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 cach

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

2015-02-17 Thread Christoph Lameter
On Tue, 17 Feb 2015, Joonsoo Kim wrote: > Hmm...so far, SLAB focus on temporal locality rather than spatial locality > as you know. Why SLAB need to consider spatial locality first in this > kmem_cache_alloc_array() case? Well we are talking about a large number of objects. And going around rando

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

2015-02-16 Thread Joonsoo Kim
On Fri, Feb 13, 2015 at 09:47:59AM -0600, Christoph Lameter wrote: > On Fri, 13 Feb 2015, Joonsoo Kim wrote: > > > > I also think that this implementation is slub-specific. For example, > > in slab case, it is always better to access local cpu cache first than > > page allocator since slab doesn't

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

2015-02-13 Thread David Rientjes
On Fri, 13 Feb 2015, Christoph Lameter wrote: > > I also think that this implementation is slub-specific. For example, > > in slab case, it is always better to access local cpu cache first than > > page allocator since slab doesn't use list to manage free objects and > > there is no cache line ove

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

2015-02-13 Thread Christoph Lameter
On Fri, 13 Feb 2015, Joonsoo Kim wrote: > > I also think that this implementation is slub-specific. For example, > in slab case, it is always better to access local cpu cache first than > page allocator since slab doesn't use list to manage free objects and > there is no cache line overhead like as

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

2015-02-12 Thread Joonsoo Kim
On Wed, Feb 11, 2015 at 12:18:07PM -0800, David Rientjes wrote: > On Wed, 11 Feb 2015, Christoph Lameter wrote: > > > > This patch is referencing functions that don't exist and can do so since > > > it's not compiled, but I think this belongs in the next patch. I also > > > think that this partic

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

2015-02-11 Thread David Rientjes
On Wed, 11 Feb 2015, Christoph Lameter wrote: > > > > Hmm, not sure why the allocator would be required to do the > > > > EXPORT_SYMBOL() if it defines kmem_cache_free_array() itself. This > > > > > > Keeping the EXPORT with the definition is the custom as far as I could > > > tell. > > > > > > >

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

2015-02-11 Thread Christoph Lameter
On Wed, 11 Feb 2015, David Rientjes wrote: > > > > > > Hmm, not sure why the allocator would be required to do the > > > EXPORT_SYMBOL() if it defines kmem_cache_free_array() itself. This > > > > Keeping the EXPORT with the definition is the custom as far as I could > > tell. > > > > If you do du

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

2015-02-11 Thread David Rientjes
On Wed, 11 Feb 2015, Christoph Lameter wrote: > > This patch is referencing functions that don't exist and can do so since > > it's not compiled, but I think this belongs in the next patch. I also > > think that this particular implementation may be slub-specific so I would > > have expected just

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

2015-02-11 Thread Christoph Lameter
On Tue, 10 Feb 2015, David Rientjes wrote: > > +int kmem_cache_alloc_array(struct kmem_cache *s, > > + gfp_t flags, size_t nr, void **p) > > +{ > > + int i = 0; > > + > > +#ifdef _HAVE_SLAB_ALLOCATOR_ARRAY_OPERATIONS > > + /* ... > > + i += slab_array_alloc_from_local(s,

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

2015-02-10 Thread David Rientjes
On Tue, 10 Feb 2015, Christoph Lameter wrote: > This patch adds the basic infrastructure for alloc / free operations > on pointer arrays. It includes a fallback function that can perform > the array operations using the single alloc and free that every > slab allocator performs. > > Allocators mu

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

2015-02-10 Thread Jesper Dangaard Brouer
On Tue, 10 Feb 2015 13:48:05 -0600 Christoph Lameter wrote: [...] > Index: linux/mm/slab_common.c > === > --- linux.orig/mm/slab_common.c > +++ linux/mm/slab_common.c > @@ -105,6 +105,83 @@ static inline int kmem_cache_sanity_chec >

[PATCH 1/3] Slab infrastructure for array operations

2015-02-10 Thread Christoph Lameter
This patch adds the basic infrastructure for alloc / free operations on pointer arrays. It includes a fallback function that can perform the array operations using the single alloc and free that every slab allocator performs. Allocators must define _HAVE_SLAB_ALLOCATOR_OPERATIONS in their header f