linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Christoph Lameter <cl@linux.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	linux-mm@kvack.org, Tejun Heo <htejun@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] mm/slab: use percpu allocator for cpu cache
Date: Mon, 25 Aug 2014 17:26:15 +0900	[thread overview]
Message-ID: <20140825082615.GA13475@js1304-P5Q-DELUXE> (raw)
In-Reply-To: <alpine.DEB.2.11.1408210918050.32524@gentwo.org>

On Thu, Aug 21, 2014 at 09:21:30AM -0500, Christoph Lameter wrote:
> On Thu, 21 Aug 2014, Joonsoo Kim wrote:
> 
> > So, this patch try to use percpu allocator in SLAB. This simplify
> > initialization step in SLAB so that we could maintain SLAB code more
> > easily.
> 
> I thought about this a couple of times but the amount of memory used for
> the per cpu arrays can be huge. In contrast to slub which needs just a
> few pointers, slab requires one pointer per object that can be in the
> local cache. CC Tj.
> 
> Lets say we have 300 caches and we allow 1000 objects to be cached per
> cpu. That is 300k pointers per cpu. 1.2M on 32 bit. 2.4M per cpu on
> 64bit.

Hello, Christoph.

Amount of memory we need to keep pointers for object is same in any case.
I know that percpu allocator occupy vmalloc space, so maybe we could
exhaust vmalloc space on 32 bit. 64 bit has no problem on it.
How many cores does largest 32 bit system have? Is it possible
to exhaust vmalloc space if we use percpu allocator?

Thanks.

--
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:[~2014-08-25  8:26 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-21  8:11 Joonsoo Kim
2014-08-21  8:11 ` [PATCH 2/3] mm/slab_common: commonize slab merge logic Joonsoo Kim
2014-08-21 14:22   ` Christoph Lameter
2014-08-25  8:26     ` Joonsoo Kim
2014-08-25 15:27   ` Christoph Lameter
2014-08-26  2:23     ` Joonsoo Kim
2014-08-26 21:23       ` Christoph Lameter
2014-08-21  8:11 ` [PATCH 3/3] mm/slab: support slab merge Joonsoo Kim
2014-08-25 15:29   ` Christoph Lameter
2014-08-26  2:26     ` Joonsoo Kim
2014-08-21 14:21 ` [PATCH 1/3] mm/slab: use percpu allocator for cpu cache Christoph Lameter
2014-08-25  8:26   ` Joonsoo Kim [this message]
2014-08-25 13:13     ` Christoph Lameter
2014-08-26  2:19       ` Joonsoo Kim
2014-08-26 21:22         ` Christoph Lameter
2014-08-27 23:37 ` Christoph Lameter
2014-09-01  0:19   ` Joonsoo Kim
2014-09-28  6:24 ` [REGRESSION] " Jeremiah Mahler
2014-09-28 16:38   ` Christoph Lameter
2014-09-29  7:44   ` Joonsoo Kim

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=20140825082615.GA13475@js1304-P5Q-DELUXE \
    --to=iamjoonsoo.kim@lge.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=htejun@gmail.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