From: Andrew Morton <akpm@osdl.org>
To: Mike Kravetz <kravetz@us.ibm.com>
Cc: penberg@cs.Helsinki.FI, clameter@sgi.com, haveblue@us.ibm.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] add slab_is_available() routine for boot code
Date: Wed, 10 May 2006 15:50:26 -0700 [thread overview]
Message-ID: <20060510155026.173c57a1.akpm@osdl.org> (raw)
In-Reply-To: <20060510205543.GI3198@w-mikek2.ibm.com>
Mike Kravetz <kravetz@us.ibm.com> wrote:
>
> slab_is_available() indicates slab based allocators are available
> for use. SPARSEMEM code needs to know this as it can be called
> at various times during the boot process.
>
> Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
>
> diff -Naupr linux-2.6.17-rc3-mm1/include/linux/slab.h linux-2.6.17-rc3-mm1.work3/include/linux/slab.h
> --- linux-2.6.17-rc3-mm1/include/linux/slab.h 2006-05-03 22:19:15.000000000 +0000
> +++ linux-2.6.17-rc3-mm1.work3/include/linux/slab.h 2006-05-10 19:15:20.000000000 +0000
> @@ -150,6 +150,7 @@ static inline void *kcalloc(size_t n, si
>
> extern void kfree(const void *);
> extern unsigned int ksize(const void *);
> +extern int slab_is_available(void);
>
> #ifdef CONFIG_NUMA
> extern void *kmem_cache_alloc_node(kmem_cache_t *, gfp_t flags, int node);
> diff -Naupr linux-2.6.17-rc3-mm1/mm/slab.c linux-2.6.17-rc3-mm1.work3/mm/slab.c
> --- linux-2.6.17-rc3-mm1/mm/slab.c 2006-05-03 22:19:16.000000000 +0000
> +++ linux-2.6.17-rc3-mm1.work3/mm/slab.c 2006-05-10 21:43:08.000000000 +0000
> @@ -694,6 +694,14 @@ static enum {
> FULL
> } g_cpucache_up;
>
> +/*
> + * used by boot code to determine if it can use slab based allocator
> + */
> +int slab_is_available(void)
> +{
> + return g_cpucache_up == FULL;
> +}
Even I can understand this ;)
> static DEFINE_PER_CPU(struct work_struct, reap_work);
>
> static void free_block(struct kmem_cache *cachep, void **objpp, int len,
> diff -Naupr linux-2.6.17-rc3-mm1/mm/sparse.c linux-2.6.17-rc3-mm1.work3/mm/sparse.c
> --- linux-2.6.17-rc3-mm1/mm/sparse.c 2006-05-03 22:19:16.000000000 +0000
> +++ linux-2.6.17-rc3-mm1.work3/mm/sparse.c 2006-05-10 19:15:56.000000000 +0000
> @@ -32,7 +32,7 @@ static struct mem_section *sparse_index_
> unsigned long array_size = SECTIONS_PER_ROOT *
> sizeof(struct mem_section);
>
> - if (system_state == SYSTEM_RUNNING)
> + if (slab_is_available())
> section = kmalloc_node(array_size, GFP_KERNEL, nid);
> else
> section = alloc_bootmem_node(NODE_DATA(nid), array_size);
Is this a needed-for-2.6.17 fix?
next prev parent reply other threads:[~2006-05-10 22:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-10 20:55 Mike Kravetz
2006-05-10 22:50 ` Andrew Morton [this message]
2006-05-10 23:00 ` Mike Kravetz
2006-05-11 3:07 ` Benjamin Herrenschmidt
2006-05-11 12:40 ` Arnd Bergmann
2006-05-11 6:15 ` Pekka J Enberg
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=20060510155026.173c57a1.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=clameter@sgi.com \
--cc=haveblue@us.ibm.com \
--cc=kravetz@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.Helsinki.FI \
/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
all inboxes | Powered by JetHome®