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
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
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
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
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
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
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
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.
> > >
> >
> >
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
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
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,
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
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
>
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
14 matches
Mail list logo