All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
	David Rientjes <rientjes@google.com>,
	linux-mm@kvack.org
Subject: Re: [RFC] slub: Simplify boot kmem_cache_cpu allocations
Date: Thu, 17 Jun 2010 10:49:33 +0200	[thread overview]
Message-ID: <4C19E19D.2020802@kernel.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1006161231420.6361@router.home>

Hello,

On 06/16/2010 07:35 PM, Christoph Lameter wrote:
>> It's primarily controlled by PERCPU_DYNAMIC_RESERVE.  I don't think
>> there will be any systematic way to do it other than sizing it
>> sufficiently.  Can you calculate the upper bound?  The constant has
>> been used primarily for optimization so how it's used needs to be
>> audited if we wanna guarantee free space in the first chunk but I
>> don't think it would be too difficult.
> 
> The upper bound is SLUB_PAGE_SHIFT * sizeof(struct kmem_cache_cpu).
> 
> Thats usually 14 * 104 bytes = 1456 bytes. This may increase to more
> than 8k given the future plans to add queues into kmem_cache_cpu.

Alright, will work on that.  Does slab allocator guarantee to return
NULL if called before initialized or is it undefined?  If latter, is
there a way to determine whether slab is initialized yet?

Thanks.

-- 
tejun

--
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:[~2010-06-17  8:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-15 19:07 slub: remove dynamic dma slab allocation Christoph Lameter
2010-06-15 19:11 ` [RFC] slub: Simplify boot kmem_cache_cpu allocations Christoph Lameter
2010-06-16  8:53   ` Tejun Heo
2010-06-16 16:33     ` Christoph Lameter
2010-06-16 17:18       ` Tejun Heo
2010-06-16 17:35         ` Christoph Lameter
2010-06-17  8:49           ` Tejun Heo [this message]
2010-06-17  9:01             ` Pekka Enberg
2010-06-17 13:43             ` Christoph Lameter
2010-06-18 16:58               ` [PATCH 1/2] percpu: make @dyn_size always mean min dyn_size in first chunk init functions Tejun Heo
2010-06-18 17:29                 ` Christoph Lameter
2010-06-18 17:31                 ` Christoph Lameter
2010-06-18 17:39                   ` Tejun Heo
2010-06-18 18:03                     ` Christoph Lameter
2010-06-19  8:23                       ` Tejun Heo
2010-06-18 16:58               ` [PATCH 2/2] percpu: allow limited allocation before slab is online Tejun Heo
2010-06-18 22:30 ` slub: remove dynamic dma slab allocation David Rientjes
2010-06-21 14:25   ` Christoph Lameter
2010-06-21 19:56     ` David Rientjes
2010-06-21 20:32       ` Christoph Lameter
2010-06-21 21:08         ` David Rientjes

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=4C19E19D.2020802@kernel.org \
    --to=tj@kernel.org \
    --cc=cl@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@cs.helsinki.fi \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.