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
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
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
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
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
On Tue, 17 Feb 2015 10:03:51 -0600 (CST)
Christoph Lameter c...@linux.com 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
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, 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 use list
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
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
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 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 overhead
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
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 particular
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
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
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, 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, nr - i, p + i);
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 a call
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 dummy functions for
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.
If you do dummy
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
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
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
On Tue, 10 Feb 2015 13:48:05 -0600 Christoph Lameter c...@linux.com 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
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 must
28 matches
Mail list logo
