linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux-foundation.org>
To: David Rientjes <rientjes@google.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>, linux-mm@kvack.org
Subject: Re: slub: remove dynamic dma slab allocation
Date: Mon, 21 Jun 2010 15:32:40 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1006211521470.9272@router.home> (raw)
In-Reply-To: <alpine.DEB.2.00.1006211234230.8367@chino.kir.corp.google.com>

On Mon, 21 Jun 2010, David Rientjes wrote:

> > You cannot do that here because this function is also used later when the
> > slab is up. There is more in the percpu allocator which we are also trying
> > to use to avoid having static kmem_cache_cpu declarations. GFP_KERNEL
> > needs to be usable during early boot otherwise functions will have to add
> > special casing for boot situations.
> >
>
> The gfp_allowed_mask only changes once irqs are enabled, so either the
> gfpflags need to be passed into init_kmem_cache_nodes again or we need to
> do something like
>
> 	gfp_t gfpflags = irqs_disabled() ? GFP_NOWAIT : GFP_KERNEL;
>
> locally.

What a mess....

> The cleanest solution would probably be to extend slab_state to be set in
> kmem_cache_init_late() to determine when we're fully initialized, though.

Not sure what the point would be. Changing slab_state does not change the
interrupt enabled/disabled state of the processor.

Is gfp_allowed_mask properly updated during boot? Then we could just use

	GFP_KERNEL & gfp_allowed_mask

in these locations? Still bad since we are wasting code on correctness
checks.

Noone thought about this when designing these checks? The checks cannot be
fixed up to consider boot time so that we do not have to do artistics in
the code?

--
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-21 20:36 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-15 19:07 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
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 [this message]
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=alpine.DEB.2.00.1006211521470.9272@router.home \
    --to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox