linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux.com>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: David Rientjes <rientjes@google.com>,
	akpm@linuxfoundation.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, penberg@kernel.org, iamjoonsoo@lge.com,
	Jesper Dangaard Brouer <brouer@redhat.com>
Subject: Re: [PATCH 1/3] Slab infrastructure for array operations
Date: Tue, 17 Feb 2015 10:03:51 -0600 (CST)	[thread overview]
Message-ID: <alpine.DEB.2.11.1502170959130.4996@gentwo.org> (raw)
In-Reply-To: <20150217051541.GA15413@js1304-P5Q-DELUXE>

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
randomly in memory is going to cause a lot of TLB misses. Spatial locality
increases the effectiveness of the processing of these objects.

> And, although we use partial list first, we can't reduce
> fragmentation as much as SLUB. Local cache may keep some free objects
> of the partial slab so just exhausting free objects of partial slab doesn't
> means that there is no free object left. For SLUB, exhausting free
> objects of partial slab means there is no free object left.

SLUB will still have the per cpu objects in the per cpu page and te per
cpu slab pages.

> 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.

> As David said, there is no implementation for SLAB yet and we have
> different opinion about implementation for SLAB. It's better
> to delay detailed implementation of kmem_cache_alloc_array()
> until implementation for SLAB is agreed. Before it, calling
> __kmem_cache_alloc_array() in kmem_cache_alloc_array() is sufficient
> to provide functionality.

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).


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2015-02-17 16:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-10 19:48 [PATCH 0/3] Slab allocator array operations V2 Christoph Lameter
2015-02-10 19:48 ` [PATCH 1/3] Slab infrastructure for array operations Christoph Lameter
2015-02-10 22:43   ` Jesper Dangaard Brouer
2015-02-10 23:58   ` David Rientjes
2015-02-11 18:47     ` Christoph Lameter
2015-02-11 20:18       ` David Rientjes
2015-02-11 22:04         ` Christoph Lameter
2015-02-12  0:35           ` David Rientjes
2015-02-13  2:35         ` Joonsoo Kim
2015-02-13 15:47           ` Christoph Lameter
2015-02-13 21:20             ` David Rientjes
2015-02-17  5:15             ` Joonsoo Kim
2015-02-17 16:03               ` Christoph Lameter [this message]
2015-02-17 21:32                 ` Jesper Dangaard Brouer
2015-02-18 23:02                   ` Christoph Lameter
2015-02-10 19:48 ` [PATCH 2/3] slub: Support " Christoph Lameter
2015-02-11  4:48   ` Jesper Dangaard Brouer
2015-02-11 19:07     ` Christoph Lameter
2015-02-11 21:43       ` Jesper Dangaard Brouer
2015-02-11 22:06         ` Christoph Lameter
2015-02-12  0:16           ` Jesper Dangaard Brouer
2015-02-12  2:46             ` Christoph Lameter
2015-02-13  2:45   ` Joonsoo Kim
2015-02-13 15:49     ` Christoph Lameter
2015-02-17  5:26       ` Joonsoo Kim
2015-02-10 19:48 ` [PATCH 3/3] Array alloc test code Christoph Lameter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.11.1502170959130.4996@gentwo.org \
    --to=cl@linux.com \
    --cc=akpm@linuxfoundation.org \
    --cc=brouer@redhat.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=iamjoonsoo@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox