[PATCH] mm: Improve documentation of page_order v2

2014-01-21 Thread Mel Gorman 
Developers occasionally try and optimise PFN scanners by using page_order
but miss that in general it requires zone->lock. This has happened twice for
compaction.c and rejected both times.  This patch clarifies the documentation
of page_order and adds a note to compaction.c why page_order is not used.

[lau...@codeaurora.org: Corrected a page_zone(page)->lock reference]
Signed-off-by: Mel Gorman 
Acked-by: Rafael Aquini 
Acked-by: Minchan Kim 
---
 mm/compaction.c | 5 -
 mm/internal.h   | 8 +---
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index f58bcd0..f91d26b 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -522,7 +522,10 @@ isolate_migratepages_range(struct zone *zone, struct 
compact_control *cc,
if (!isolation_suitable(cc, page))
goto next_pageblock;
 
-   /* Skip if free */
+   /*
+* Skip if free. page_order cannot be used without zone->lock
+* as nothing prevents parallel allocations or buddy merging.
+*/
if (PageBuddy(page))
continue;
 
diff --git a/mm/internal.h b/mm/internal.h
index 684f7aa..09cd8be 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -144,9 +144,11 @@ isolate_migratepages_range(struct zone *zone, struct 
compact_control *cc,
 #endif
 
 /*
- * function for dealing with page's order in buddy system.
- * zone->lock is already acquired when we use these.
- * So, we don't need atomic page->flags operations here.
+ * This functions returns the order of a free page in the buddy system. In
+ * general, page_zone(page)->lock must be held by the caller to prevent the
+ * page being allocated in parallel and returning garbage as the order. If the
+ * caller does not hold page_zone(page)->lock, they must guarantee that the
+ * page cannot be allocated or merged in parallel.
  */
 static inline unsigned long page_order(struct page *page)
 {

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mm: Improve documentation of page_order v2

2014-01-21 Thread Mel Gorman 
Developers occasionally try and optimise PFN scanners by using page_order
but miss that in general it requires zone-lock. This has happened twice for
compaction.c and rejected both times.  This patch clarifies the documentation
of page_order and adds a note to compaction.c why page_order is not used.

[lau...@codeaurora.org: Corrected a page_zone(page)-lock reference]
Signed-off-by: Mel Gorman mgor...@suse.de
Acked-by: Rafael Aquini aqu...@redhat.com
Acked-by: Minchan Kim minc...@kernel.org
---
 mm/compaction.c | 5 -
 mm/internal.h   | 8 +---
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index f58bcd0..f91d26b 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -522,7 +522,10 @@ isolate_migratepages_range(struct zone *zone, struct 
compact_control *cc,
if (!isolation_suitable(cc, page))
goto next_pageblock;
 
-   /* Skip if free */
+   /*
+* Skip if free. page_order cannot be used without zone-lock
+* as nothing prevents parallel allocations or buddy merging.
+*/
if (PageBuddy(page))
continue;
 
diff --git a/mm/internal.h b/mm/internal.h
index 684f7aa..09cd8be 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -144,9 +144,11 @@ isolate_migratepages_range(struct zone *zone, struct 
compact_control *cc,
 #endif
 
 /*
- * function for dealing with page's order in buddy system.
- * zone-lock is already acquired when we use these.
- * So, we don't need atomic page-flags operations here.
+ * This functions returns the order of a free page in the buddy system. In
+ * general, page_zone(page)-lock must be held by the caller to prevent the
+ * page being allocated in parallel and returning garbage as the order. If the
+ * caller does not hold page_zone(page)-lock, they must guarantee that the
+ * page cannot be allocated or merged in parallel.
  */
 static inline unsigned long page_order(struct page *page)
 {

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: Improve documentation of page_order

2014-01-19 Thread Minchan Kim 
On Fri, Jan 17, 2014 at 02:32:21PM +, Mel Gorman wrote:
> Developers occasionally try and optimise PFN scanners by using page_order
> but miss that in general it requires zone->lock. This has happened twice for
> compaction.c and rejected both times.  This patch clarifies the documentation
> of page_order and adds a note to compaction.c why page_order is not used.
> 
> Signed-off-by: Mel Gorman 

Except Laura pointed out,

Acked-by: Minchan Kim 

Thanks for following up this issue without forgetting.
-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: Improve documentation of page_order

2014-01-19 Thread Minchan Kim 
On Fri, Jan 17, 2014 at 02:32:21PM +, Mel Gorman wrote:
 Developers occasionally try and optimise PFN scanners by using page_order
 but miss that in general it requires zone-lock. This has happened twice for
 compaction.c and rejected both times.  This patch clarifies the documentation
 of page_order and adds a note to compaction.c why page_order is not used.
 
 Signed-off-by: Mel Gorman mgor...@suse.de

Except Laura pointed out,

Acked-by: Minchan Kim minc...@kernel.org

Thanks for following up this issue without forgetting.
-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: Improve documentation of page_order

2014-01-17 Thread Mel Gorman 
On Fri, Jan 17, 2014 at 10:53:50AM -0800, Laura Abbott wrote:
> On 1/17/2014 6:32 AM, Mel Gorman wrote:
> >Developers occasionally try and optimise PFN scanners by using page_order
> >but miss that in general it requires zone->lock. This has happened twice for
> >compaction.c and rejected both times.  This patch clarifies the documentation
> >of page_order and adds a note to compaction.c why page_order is not used.
> >
> >Signed-off-by: Mel Gorman 
> >---
> >  mm/compaction.c | 5 -
> >  mm/internal.h   | 8 +---
> >  2 files changed, 9 insertions(+), 4 deletions(-)
> >
> >diff --git a/mm/compaction.c b/mm/compaction.c
> >index f58bcd0..f91d26b 100644
> >--- a/mm/compaction.c
> >+++ b/mm/compaction.c
> >@@ -522,7 +522,10 @@ isolate_migratepages_range(struct zone *zone, struct 
> >compact_control *cc,
> > if (!isolation_suitable(cc, page))
> > goto next_pageblock;
> >
> >-/* Skip if free */
> >+/*
> >+ * Skip if free. page_order cannot be used without zone->lock
> >+ * as nothing prevents parallel allocations or buddy merging.
> >+ */
> > if (PageBuddy(page))
> > continue;
> >
> >diff --git a/mm/internal.h b/mm/internal.h
> >index 684f7aa..09cd8be 100644
> >--- a/mm/internal.h
> >+++ b/mm/internal.h
> >@@ -144,9 +144,11 @@ isolate_migratepages_range(struct zone *zone, struct 
> >compact_control *cc,
> >  #endif
> >
> >  /*
> >- * function for dealing with page's order in buddy system.
> >- * zone->lock is already acquired when we use these.
> >- * So, we don't need atomic page->flags operations here.
> >+ * This functions returns the order of a free page in the buddy system.
> >+ * In general, page_zone(page)->lock must be held by the caller to prevent
> >+ * the page being allocated in parallel and returning garbage as the order.
> >+ * If the caller does not hold page_zone(page), they must guarantee that
>   page_zone(page)->lock here?

*sigh*

Yes, thanks.

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: Improve documentation of page_order

2014-01-17 Thread Laura Abbott 

On 1/17/2014 6:32 AM, Mel Gorman wrote:

Developers occasionally try and optimise PFN scanners by using page_order
but miss that in general it requires zone->lock. This has happened twice for
compaction.c and rejected both times.  This patch clarifies the documentation
of page_order and adds a note to compaction.c why page_order is not used.

Signed-off-by: Mel Gorman 
---
  mm/compaction.c | 5 -
  mm/internal.h   | 8 +---
  2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index f58bcd0..f91d26b 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -522,7 +522,10 @@ isolate_migratepages_range(struct zone *zone, struct 
compact_control *cc,
if (!isolation_suitable(cc, page))
goto next_pageblock;

-   /* Skip if free */
+   /*
+* Skip if free. page_order cannot be used without zone->lock
+* as nothing prevents parallel allocations or buddy merging.
+*/
if (PageBuddy(page))
continue;

diff --git a/mm/internal.h b/mm/internal.h
index 684f7aa..09cd8be 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -144,9 +144,11 @@ isolate_migratepages_range(struct zone *zone, struct 
compact_control *cc,
  #endif

  /*
- * function for dealing with page's order in buddy system.
- * zone->lock is already acquired when we use these.
- * So, we don't need atomic page->flags operations here.
+ * This functions returns the order of a free page in the buddy system.
+ * In general, page_zone(page)->lock must be held by the caller to prevent
+ * the page being allocated in parallel and returning garbage as the order.
+ * If the caller does not hold page_zone(page), they must guarantee that

  page_zone(page)->lock here?

+ * the page cannot be allocated or merged in parallel.
   */
  static inline unsigned long page_order(struct page *page)
  {

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"d...@kvack.org;> em...@kvack.org 




--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: Improve documentation of page_order

2014-01-17 Thread Rafael Aquini 
On Fri, Jan 17, 2014 at 02:32:21PM +, Mel Gorman wrote:
> Developers occasionally try and optimise PFN scanners by using page_order
> but miss that in general it requires zone->lock. This has happened twice for
> compaction.c and rejected both times.  This patch clarifies the documentation
> of page_order and adds a note to compaction.c why page_order is not used.
> 
> Signed-off-by: Mel Gorman 
> ---
>  mm/compaction.c | 5 -
>  mm/internal.h   | 8 +---
>  2 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index f58bcd0..f91d26b 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -522,7 +522,10 @@ isolate_migratepages_range(struct zone *zone, struct 
> compact_control *cc,
>   if (!isolation_suitable(cc, page))
>   goto next_pageblock;
>  
> - /* Skip if free */
> + /*
> +  * Skip if free. page_order cannot be used without zone->lock
> +  * as nothing prevents parallel allocations or buddy merging.
> +  */
>   if (PageBuddy(page))
>   continue;
>  
> diff --git a/mm/internal.h b/mm/internal.h
> index 684f7aa..09cd8be 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -144,9 +144,11 @@ isolate_migratepages_range(struct zone *zone, struct 
> compact_control *cc,
>  #endif
>  
>  /*
> - * function for dealing with page's order in buddy system.
> - * zone->lock is already acquired when we use these.
> - * So, we don't need atomic page->flags operations here.
> + * This functions returns the order of a free page in the buddy system.
> + * In general, page_zone(page)->lock must be held by the caller to prevent
> + * the page being allocated in parallel and returning garbage as the order.
> + * If the caller does not hold page_zone(page), they must guarantee that
> + * the page cannot be allocated or merged in parallel.
>   */
>  static inline unsigned long page_order(struct page *page)
>  {

Acked-by: Rafael Aquini 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mm: Improve documentation of page_order

2014-01-17 Thread Mel Gorman 
Developers occasionally try and optimise PFN scanners by using page_order
but miss that in general it requires zone->lock. This has happened twice for
compaction.c and rejected both times.  This patch clarifies the documentation
of page_order and adds a note to compaction.c why page_order is not used.

Signed-off-by: Mel Gorman 
---
 mm/compaction.c | 5 -
 mm/internal.h   | 8 +---
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index f58bcd0..f91d26b 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -522,7 +522,10 @@ isolate_migratepages_range(struct zone *zone, struct 
compact_control *cc,
if (!isolation_suitable(cc, page))
goto next_pageblock;
 
-   /* Skip if free */
+   /*
+* Skip if free. page_order cannot be used without zone->lock
+* as nothing prevents parallel allocations or buddy merging.
+*/
if (PageBuddy(page))
continue;
 
diff --git a/mm/internal.h b/mm/internal.h
index 684f7aa..09cd8be 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -144,9 +144,11 @@ isolate_migratepages_range(struct zone *zone, struct 
compact_control *cc,
 #endif
 
 /*
- * function for dealing with page's order in buddy system.
- * zone->lock is already acquired when we use these.
- * So, we don't need atomic page->flags operations here.
+ * This functions returns the order of a free page in the buddy system.
+ * In general, page_zone(page)->lock must be held by the caller to prevent
+ * the page being allocated in parallel and returning garbage as the order.
+ * If the caller does not hold page_zone(page), they must guarantee that
+ * the page cannot be allocated or merged in parallel.
  */
 static inline unsigned long page_order(struct page *page)
 {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mm: Improve documentation of page_order

2014-01-17 Thread Mel Gorman 
Developers occasionally try and optimise PFN scanners by using page_order
but miss that in general it requires zone-lock. This has happened twice for
compaction.c and rejected both times.  This patch clarifies the documentation
of page_order and adds a note to compaction.c why page_order is not used.

Signed-off-by: Mel Gorman mgor...@suse.de
---
 mm/compaction.c | 5 -
 mm/internal.h   | 8 +---
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index f58bcd0..f91d26b 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -522,7 +522,10 @@ isolate_migratepages_range(struct zone *zone, struct 
compact_control *cc,
if (!isolation_suitable(cc, page))
goto next_pageblock;
 
-   /* Skip if free */
+   /*
+* Skip if free. page_order cannot be used without zone-lock
+* as nothing prevents parallel allocations or buddy merging.
+*/
if (PageBuddy(page))
continue;
 
diff --git a/mm/internal.h b/mm/internal.h
index 684f7aa..09cd8be 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -144,9 +144,11 @@ isolate_migratepages_range(struct zone *zone, struct 
compact_control *cc,
 #endif
 
 /*
- * function for dealing with page's order in buddy system.
- * zone-lock is already acquired when we use these.
- * So, we don't need atomic page-flags operations here.
+ * This functions returns the order of a free page in the buddy system.
+ * In general, page_zone(page)-lock must be held by the caller to prevent
+ * the page being allocated in parallel and returning garbage as the order.
+ * If the caller does not hold page_zone(page), they must guarantee that
+ * the page cannot be allocated or merged in parallel.
  */
 static inline unsigned long page_order(struct page *page)
 {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: Improve documentation of page_order

2014-01-17 Thread Rafael Aquini 
On Fri, Jan 17, 2014 at 02:32:21PM +, Mel Gorman wrote:
 Developers occasionally try and optimise PFN scanners by using page_order
 but miss that in general it requires zone-lock. This has happened twice for
 compaction.c and rejected both times.  This patch clarifies the documentation
 of page_order and adds a note to compaction.c why page_order is not used.
 
 Signed-off-by: Mel Gorman mgor...@suse.de
 ---
  mm/compaction.c | 5 -
  mm/internal.h   | 8 +---
  2 files changed, 9 insertions(+), 4 deletions(-)
 
 diff --git a/mm/compaction.c b/mm/compaction.c
 index f58bcd0..f91d26b 100644
 --- a/mm/compaction.c
 +++ b/mm/compaction.c
 @@ -522,7 +522,10 @@ isolate_migratepages_range(struct zone *zone, struct 
 compact_control *cc,
   if (!isolation_suitable(cc, page))
   goto next_pageblock;
  
 - /* Skip if free */
 + /*
 +  * Skip if free. page_order cannot be used without zone-lock
 +  * as nothing prevents parallel allocations or buddy merging.
 +  */
   if (PageBuddy(page))
   continue;
  
 diff --git a/mm/internal.h b/mm/internal.h
 index 684f7aa..09cd8be 100644
 --- a/mm/internal.h
 +++ b/mm/internal.h
 @@ -144,9 +144,11 @@ isolate_migratepages_range(struct zone *zone, struct 
 compact_control *cc,
  #endif
  
  /*
 - * function for dealing with page's order in buddy system.
 - * zone-lock is already acquired when we use these.
 - * So, we don't need atomic page-flags operations here.
 + * This functions returns the order of a free page in the buddy system.
 + * In general, page_zone(page)-lock must be held by the caller to prevent
 + * the page being allocated in parallel and returning garbage as the order.
 + * If the caller does not hold page_zone(page), they must guarantee that
 + * the page cannot be allocated or merged in parallel.
   */
  static inline unsigned long page_order(struct page *page)
  {

Acked-by: Rafael Aquini aqu...@redhat.com


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: Improve documentation of page_order

2014-01-17 Thread Laura Abbott 

On 1/17/2014 6:32 AM, Mel Gorman wrote:

Developers occasionally try and optimise PFN scanners by using page_order
but miss that in general it requires zone-lock. This has happened twice for
compaction.c and rejected both times.  This patch clarifies the documentation
of page_order and adds a note to compaction.c why page_order is not used.

Signed-off-by: Mel Gorman mgor...@suse.de
---
  mm/compaction.c | 5 -
  mm/internal.h   | 8 +---
  2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index f58bcd0..f91d26b 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -522,7 +522,10 @@ isolate_migratepages_range(struct zone *zone, struct 
compact_control *cc,
if (!isolation_suitable(cc, page))
goto next_pageblock;

-   /* Skip if free */
+   /*
+* Skip if free. page_order cannot be used without zone-lock
+* as nothing prevents parallel allocations or buddy merging.
+*/
if (PageBuddy(page))
continue;

diff --git a/mm/internal.h b/mm/internal.h
index 684f7aa..09cd8be 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -144,9 +144,11 @@ isolate_migratepages_range(struct zone *zone, struct 
compact_control *cc,
  #endif

  /*
- * function for dealing with page's order in buddy system.
- * zone-lock is already acquired when we use these.
- * So, we don't need atomic page-flags operations here.
+ * This functions returns the order of a free page in the buddy system.
+ * In general, page_zone(page)-lock must be held by the caller to prevent
+ * the page being allocated in parallel and returning garbage as the order.
+ * If the caller does not hold page_zone(page), they must guarantee that

  page_zone(page)-lock here?

+ * the page cannot be allocated or merged in parallel.
   */
  static inline unsigned long page_order(struct page *page)
  {

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a




--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: Improve documentation of page_order

2014-01-17 Thread Mel Gorman 
On Fri, Jan 17, 2014 at 10:53:50AM -0800, Laura Abbott wrote:
 On 1/17/2014 6:32 AM, Mel Gorman wrote:
 Developers occasionally try and optimise PFN scanners by using page_order
 but miss that in general it requires zone-lock. This has happened twice for
 compaction.c and rejected both times.  This patch clarifies the documentation
 of page_order and adds a note to compaction.c why page_order is not used.
 
 Signed-off-by: Mel Gorman mgor...@suse.de
 ---
   mm/compaction.c | 5 -
   mm/internal.h   | 8 +---
   2 files changed, 9 insertions(+), 4 deletions(-)
 
 diff --git a/mm/compaction.c b/mm/compaction.c
 index f58bcd0..f91d26b 100644
 --- a/mm/compaction.c
 +++ b/mm/compaction.c
 @@ -522,7 +522,10 @@ isolate_migratepages_range(struct zone *zone, struct 
 compact_control *cc,
  if (!isolation_suitable(cc, page))
  goto next_pageblock;
 
 -/* Skip if free */
 +/*
 + * Skip if free. page_order cannot be used without zone-lock
 + * as nothing prevents parallel allocations or buddy merging.
 + */
  if (PageBuddy(page))
  continue;
 
 diff --git a/mm/internal.h b/mm/internal.h
 index 684f7aa..09cd8be 100644
 --- a/mm/internal.h
 +++ b/mm/internal.h
 @@ -144,9 +144,11 @@ isolate_migratepages_range(struct zone *zone, struct 
 compact_control *cc,
   #endif
 
   /*
 - * function for dealing with page's order in buddy system.
 - * zone-lock is already acquired when we use these.
 - * So, we don't need atomic page-flags operations here.
 + * This functions returns the order of a free page in the buddy system.
 + * In general, page_zone(page)-lock must be held by the caller to prevent
 + * the page being allocated in parallel and returning garbage as the order.
 + * If the caller does not hold page_zone(page), they must guarantee that
   page_zone(page)-lock here?

*sigh*

Yes, thanks.

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/