From: Pekka Enberg <penberg@cs.helsinki.fi>
To: Tejun Heo <tj@kernel.org>
Cc: Christoph Lameter <cl@linux-foundation.org>,
David Rientjes <rientjes@google.com>,
linux-mm@kvack.org
Subject: Re: [RFC] slub: Simplify boot kmem_cache_cpu allocations
Date: Thu, 17 Jun 2010 12:01:42 +0300 [thread overview]
Message-ID: <4C19E476.9010303@cs.helsinki.fi> (raw)
In-Reply-To: <4C19E19D.2020802@kernel.org>
On 6/17/10 11:49 AM, Tejun Heo wrote:
> 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?
It's undefined and you can use slab_is_available() to check if it's
available or not.
--
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>
next prev parent reply other threads:[~2010-06-17 9:01 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
2010-06-17 9:01 ` Pekka Enberg [this message]
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=4C19E476.9010303@cs.helsinki.fi \
--to=penberg@cs.helsinki.fi \
--cc=cl@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=tj@kernel.org \
/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.