From: Andrew Morton <akpm@linux-foundation.org>
To: David Rientjes <rientjes@google.com>
Cc: Glauber Costa <glommer@parallels.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter <cl@linux.com>, Mel Gorman <mgorman@suse.de>
Subject: Re: [PATCH] make GFP_NOTRACK flag unconditional
Date: Mon, 15 Oct 2012 21:40:40 -0700 [thread overview]
Message-ID: <20121015214040.4ef190eb.akpm@linux-foundation.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1210152102220.5400@chino.kir.corp.google.com>
On Mon, 15 Oct 2012 21:02:45 -0700 (PDT) David Rientjes <rientjes@google.com> wrote:
> On Tue, 2 Oct 2012, David Rientjes wrote:
>
> > > There was a general sentiment in a recent discussion (See
> > > https://lkml.org/lkml/2012/9/18/258) that the __GFP flags should be
> > > defined unconditionally. Currently, the only offender is GFP_NOTRACK,
> > > which is conditional to KMEMCHECK.
> > >
> > > This simple patch makes it unconditional.
> > >
> > > Signed-off-by: Glauber Costa <glommer@parallels.com>
> > > CC: Christoph Lameter <cl@linux.com>
> > > CC: Mel Gorman <mgorman@suse.de>
> > > CC: Andrew Morton <akpm@linux-foundation.org>
> >
> > Acked-by: David Rientjes <rientjes@google.com>
> >
> > I think it was done this way to show that if CONFIG_KMEMCHECK=n then the
> > bit could be reused for something else but I can't think of any reason why
> > that would be useful; what would need to add a gfp bit that would also
> > happen to depend on CONFIG_KMEMCHECK=n? Nothing comes to mind to save a
> > bit.
> >
> > There are other cases of this as well, like __GFP_OTHER_NODE which is only
> > useful for thp and it's defined unconditionally. So this seems fine to
> > me.
> >
>
> Still missing from linux-next as of this morning, I think this patch
> should be merged.
It's in 3.7-rc1.
commit 3e648ebe076390018c317881d7d926f24d7bac6b
Author: Glauber Costa <glommer@parallels.com>
Date: Mon Oct 8 16:33:52 2012 -0700
make GFP_NOTRACK definition unconditional
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: David Rientjes <rientjes@google.com>
Cc: Glauber Costa <glommer@parallels.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter <cl@linux.com>, Mel Gorman <mgorman@suse.de>
Subject: Re: [PATCH] make GFP_NOTRACK flag unconditional
Date: Mon, 15 Oct 2012 21:40:40 -0700 [thread overview]
Message-ID: <20121015214040.4ef190eb.akpm@linux-foundation.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1210152102220.5400@chino.kir.corp.google.com>
On Mon, 15 Oct 2012 21:02:45 -0700 (PDT) David Rientjes <rientjes@google.com> wrote:
> On Tue, 2 Oct 2012, David Rientjes wrote:
>
> > > There was a general sentiment in a recent discussion (See
> > > https://lkml.org/lkml/2012/9/18/258) that the __GFP flags should be
> > > defined unconditionally. Currently, the only offender is GFP_NOTRACK,
> > > which is conditional to KMEMCHECK.
> > >
> > > This simple patch makes it unconditional.
> > >
> > > Signed-off-by: Glauber Costa <glommer@parallels.com>
> > > CC: Christoph Lameter <cl@linux.com>
> > > CC: Mel Gorman <mgorman@suse.de>
> > > CC: Andrew Morton <akpm@linux-foundation.org>
> >
> > Acked-by: David Rientjes <rientjes@google.com>
> >
> > I think it was done this way to show that if CONFIG_KMEMCHECK=n then the
> > bit could be reused for something else but I can't think of any reason why
> > that would be useful; what would need to add a gfp bit that would also
> > happen to depend on CONFIG_KMEMCHECK=n? Nothing comes to mind to save a
> > bit.
> >
> > There are other cases of this as well, like __GFP_OTHER_NODE which is only
> > useful for thp and it's defined unconditionally. So this seems fine to
> > me.
> >
>
> Still missing from linux-next as of this morning, I think this patch
> should be merged.
It's in 3.7-rc1.
commit 3e648ebe076390018c317881d7d926f24d7bac6b
Author: Glauber Costa <glommer@parallels.com>
Date: Mon Oct 8 16:33:52 2012 -0700
make GFP_NOTRACK definition unconditional
next prev parent reply other threads:[~2012-10-16 4:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-28 9:56 [PATCH] make GFP_NOTRACK flag unconditional Glauber Costa
2012-09-28 9:56 ` Glauber Costa
2012-09-28 13:19 ` Mel Gorman
2012-09-28 13:19 ` Mel Gorman
2012-09-28 14:28 ` Christoph Lameter
2012-09-28 14:28 ` Christoph Lameter
2012-09-28 14:29 ` Glauber Costa
2012-09-28 14:29 ` Glauber Costa
2012-09-28 16:40 ` Christoph Lameter
2012-09-28 16:40 ` Christoph Lameter
2012-10-03 5:00 ` David Rientjes
2012-10-03 5:00 ` David Rientjes
2012-10-16 4:02 ` David Rientjes
2012-10-16 4:02 ` David Rientjes
2012-10-16 4:40 ` Andrew Morton [this message]
2012-10-16 4:40 ` Andrew Morton
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=20121015214040.4ef190eb.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=glommer@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--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.