[PATCH] make GFP_NOTRACK flag unconditional

[PATCH] make GFP_NOTRACK flag unconditional

[Glauber Costa]

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>
---
 include/linux/gfp.h | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index f9bc873..02c1c97 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -30,11 +30,7 @@ struct vm_area_struct;
 #define ___GFP_HARDWALL		0x20000u
 #define ___GFP_THISNODE		0x40000u
 #define ___GFP_RECLAIMABLE	0x80000u
-#ifdef CONFIG_KMEMCHECK
 #define ___GFP_NOTRACK		0x200000u
-#else
-#define ___GFP_NOTRACK		0
-#endif
 #define ___GFP_OTHER_NODE	0x800000u
 #define ___GFP_WRITE		0x1000000u
 
-- 
1.7.11.4

--
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>

Re: [PATCH] make GFP_NOTRACK flag unconditional

[Mel Gorman]

On Fri, Sep 28, 2012 at 01:56:34PM +0400, Glauber Costa 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: Mel Gorman <mgorman@suse.de>

-- 
Mel Gorman
SUSE Labs

--
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>

Re: [PATCH] make GFP_NOTRACK flag unconditional

[Christoph Lameter]

On Fri, 28 Sep 2012, Glauber Costa 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.

__GFP_NOTRACK is only used in context where CONFIG_KMEMCHECK is defined?

If that is not the case then you need to define GFP_NOTRACK and substitute
it where necessary.

--
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>

Re: [PATCH] make GFP_NOTRACK flag unconditional

[Glauber Costa]

On 09/28/2012 06:28 PM, Christoph Lameter wrote:
> On Fri, 28 Sep 2012, Glauber Costa 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.
> 
> __GFP_NOTRACK is only used in context where CONFIG_KMEMCHECK is defined?
> 
> If that is not the case then you need to define GFP_NOTRACK and substitute
> it where necessary.
> 

The flag is passed around extensively, but I was imagining the whole
point of that is that having the flag itself is harmless, and will be
ignored by the page allocator ?


--
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>

Re: [PATCH] make GFP_NOTRACK flag unconditional

[Christoph Lameter]

On Fri, 28 Sep 2012, Glauber Costa wrote:

> On 09/28/2012 06:28 PM, Christoph Lameter wrote:
> > On Fri, 28 Sep 2012, Glauber Costa 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.
> >
> > __GFP_NOTRACK is only used in context where CONFIG_KMEMCHECK is defined?
> >
> > If that is not the case then you need to define GFP_NOTRACK and substitute
> > it where necessary.
> >
>
> The flag is passed around extensively, but I was imagining the whole
> point of that is that having the flag itself is harmless, and will be
> ignored by the page allocator ?

Looking through it shows almost nothing that is affected.

One thing though is that defining __GFP_NOTRACK to 0 eliminates an "or"
operation in alloc_slab_page().

That is already on the slob path so I guess that is minimal

Acked-by: Christoph Lameter <cl@linux.com>

--
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>

Re: [PATCH] make GFP_NOTRACK flag unconditional

[David Rientjes]

On Fri, 28 Sep 2012, Glauber Costa 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.

--
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>

Re: [PATCH] make GFP_NOTRACK flag unconditional

[David Rientjes]

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.

--
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>

Re: [PATCH] make GFP_NOTRACK flag unconditional

[Andrew Morton]

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>