All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@suse.de>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Ingo Molnar <mingo@elte.hu>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	benh@kernel.crashing.org, akpm@linux-foundation.org,
	cl@linux-foundation.org, torvalds@linux-foundation.org
Subject: Re: [PATCH v2] slab,slub: ignore __GFP_WAIT if we're booting or suspending
Date: Fri, 12 Jun 2009 12:15:11 +0200	[thread overview]
Message-ID: <20090612101511.GC13607@wotan.suse.de> (raw)
In-Reply-To: <84144f020906120311x7c7dd628s82e3ca9a840f9890@mail.gmail.com>

On Fri, Jun 12, 2009 at 01:11:52PM +0300, Pekka Enberg wrote:
> Hi Ingo,
> 
> On Fri, Jun 12, 2009 at 1:07 PM, Ingo Molnar<mingo@elte.hu> wrote:
> > IMHO such invisible side-channels modifying the semantics of GFP
> > flags is a bit dubious.
> >
> > We could do GFP_INIT or GFP_BOOT. These can imply other useful
> > modifiers as well: panic-on-failure for example. (this would clean
> > up a fair amount of init code that currently checks for an panics on
> > allocation failure.)
> 
> OK, but that means we need to fix up every single caller. I'm fine
> with that but Ben is not. As I am unable to test powerpc here, I am
> inclined to just merge Ben's patch as "obviously correct".

I agree with Ingo though that exposing it as a gfp modifier is
not so good. I just like the implementation to mask off GFP_WAIT
better, and also prefer not to test system state, but have someone
just call into slab to tell it not to unconditionally enable
interrupts.

> That does not mean we can't introduce GFP_BOOT later on if we want to. Hmm?

Yes, with sufficient warnings in place, I don't think it should be
too error prone to clean up remaining code over the course of
a few releases.


WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <npiggin@suse.de>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Ingo Molnar <mingo@elte.hu>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	benh@kernel.crashing.org, akpm@linux-foundation.org,
	cl@linux-foundation.org, torvalds@linux-foundation.org
Subject: Re: [PATCH v2] slab,slub: ignore __GFP_WAIT if we're booting or suspending
Date: Fri, 12 Jun 2009 12:15:11 +0200	[thread overview]
Message-ID: <20090612101511.GC13607@wotan.suse.de> (raw)
In-Reply-To: <84144f020906120311x7c7dd628s82e3ca9a840f9890@mail.gmail.com>

On Fri, Jun 12, 2009 at 01:11:52PM +0300, Pekka Enberg wrote:
> Hi Ingo,
> 
> On Fri, Jun 12, 2009 at 1:07 PM, Ingo Molnar<mingo@elte.hu> wrote:
> > IMHO such invisible side-channels modifying the semantics of GFP
> > flags is a bit dubious.
> >
> > We could do GFP_INIT or GFP_BOOT. These can imply other useful
> > modifiers as well: panic-on-failure for example. (this would clean
> > up a fair amount of init code that currently checks for an panics on
> > allocation failure.)
> 
> OK, but that means we need to fix up every single caller. I'm fine
> with that but Ben is not. As I am unable to test powerpc here, I am
> inclined to just merge Ben's patch as "obviously correct".

I agree with Ingo though that exposing it as a gfp modifier is
not so good. I just like the implementation to mask off GFP_WAIT
better, and also prefer not to test system state, but have someone
just call into slab to tell it not to unconditionally enable
interrupts.

> That does not mean we can't introduce GFP_BOOT later on if we want to. Hmm?

Yes, with sufficient warnings in place, I don't think it should be
too error prone to clean up remaining code over the course of
a few releases.

--
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:[~2009-06-12 10:15 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-12  8:13 [PATCH 2/2] slab,slub: ignore __GFP_WAIT if we're booting or suspending Pekka J Enberg
2009-06-12  8:13 ` Pekka J Enberg
2009-06-12  9:03 ` [PATCH v2] " Pekka J Enberg
2009-06-12  9:03   ` Pekka J Enberg
2009-06-12  9:10   ` Ingo Molnar
2009-06-12  9:10     ` Ingo Molnar
2009-06-12  9:21     ` Benjamin Herrenschmidt
2009-06-12  9:21       ` Benjamin Herrenschmidt
2009-06-12  9:24       ` Pekka Enberg
2009-06-12  9:24         ` Pekka Enberg
2009-06-12  9:36         ` Benjamin Herrenschmidt
2009-06-12  9:36           ` Benjamin Herrenschmidt
2009-06-12  9:45           ` Pekka J Enberg
2009-06-12  9:45             ` Pekka J Enberg
2009-06-12  9:58             ` Benjamin Herrenschmidt
2009-06-12  9:58               ` Benjamin Herrenschmidt
2009-06-12 10:00               ` Pekka Enberg
2009-06-12 10:00                 ` Pekka Enberg
2009-06-12 15:22             ` Andrew Morton
2009-06-12 15:22               ` Andrew Morton
2009-06-12  9:49     ` Pekka Enberg
2009-06-12  9:49       ` Pekka Enberg
2009-06-12  9:52       ` Nick Piggin
2009-06-12  9:52         ` Nick Piggin
2009-06-12  9:54         ` Pekka Enberg
2009-06-12  9:54           ` Pekka Enberg
2009-06-12  9:59         ` Benjamin Herrenschmidt
2009-06-12  9:59           ` Benjamin Herrenschmidt
2009-06-25  4:38           ` Nick Piggin
2009-06-25  4:38             ` Nick Piggin
2009-06-12 10:07       ` Ingo Molnar
2009-06-12 10:07         ` Ingo Molnar
2009-06-12 10:11         ` Pekka Enberg
2009-06-12 10:11           ` Pekka Enberg
2009-06-12 10:15           ` Nick Piggin [this message]
2009-06-12 10:15             ` Nick Piggin
2009-06-12 10:30             ` Pekka J Enberg
2009-06-12 10:30               ` Pekka J Enberg
2009-06-12 10:32               ` Pekka Enberg
2009-06-12 10:32                 ` Pekka Enberg
2009-06-12 15:16               ` Linus Torvalds
2009-06-12 15:16                 ` Linus Torvalds
2009-06-12 15:16                 ` Pekka Enberg
2009-06-12 15:16                   ` Pekka Enberg
2009-06-12 11:13             ` Benjamin Herrenschmidt
2009-06-12 11:13               ` Benjamin Herrenschmidt
2009-06-12 11:24               ` Benjamin Herrenschmidt
2009-06-12 11:24                 ` Benjamin Herrenschmidt
2009-06-12 11:11           ` Benjamin Herrenschmidt
2009-06-12 11:11             ` Benjamin Herrenschmidt
2009-06-12 11:34             ` Pekka Enberg
2009-06-12 11:34               ` Pekka Enberg
2009-06-12 11:41               ` Benjamin Herrenschmidt
2009-06-12 11:41                 ` Benjamin Herrenschmidt
2009-06-12 11:43                 ` Pekka Enberg
2009-06-12 11:43                   ` Pekka Enberg
2009-06-12 15:30               ` Andrew Morton
2009-06-12 15:30                 ` Andrew Morton
2009-06-12 21:42                 ` Benjamin Herrenschmidt
2009-06-12 21:42                   ` Benjamin Herrenschmidt
2009-06-25  4:41                 ` Nick Piggin
2009-06-25  4:41                   ` Nick Piggin
2009-06-12 11:09         ` Benjamin Herrenschmidt
2009-06-12 11:09           ` Benjamin Herrenschmidt
2009-06-12 15:04   ` Linus Torvalds
2009-06-12 15:04     ` Linus Torvalds
2009-06-12 15:05     ` Pekka Enberg
2009-06-12 15:05       ` Pekka Enberg
2009-06-19 14:59   ` Pavel Machek
2009-06-19 14:59     ` Pavel Machek
2009-06-19 22:27     ` Benjamin Herrenschmidt
2009-06-19 22:27       ` Benjamin Herrenschmidt
2009-06-19 23:23       ` Pavel Machek
2009-06-19 23:23         ` Pavel Machek
2009-06-19 23:50         ` Benjamin Herrenschmidt
2009-06-19 23:50           ` Benjamin Herrenschmidt
2009-06-20  0:28           ` Pavel Machek
2009-06-20  0:28             ` Pavel Machek
2009-06-20  2:10             ` Benjamin Herrenschmidt
2009-06-20  2:10               ` Benjamin Herrenschmidt
2009-06-21  6:18               ` Pavel Machek
2009-06-21  6:18                 ` Pavel Machek
2009-06-21  9:31                 ` Benjamin Herrenschmidt
2009-06-21  9:31                   ` Benjamin Herrenschmidt
2009-06-25  4:34                   ` Nick Piggin
2009-06-25  4:34                     ` Nick Piggin
2009-06-25  9:56                     ` Benjamin Herrenschmidt
2009-06-25  9:56                       ` Benjamin Herrenschmidt

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=20090612101511.GC13607@wotan.suse.de \
    --to=npiggin@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=cl@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=penberg@cs.helsinki.fi \
    --cc=torvalds@linux-foundation.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.