diff mbox

[RFC,v2,05/11] mm: thp: Correct the HPAGE_PMD_ORDER check.

Message ID 1368006763-30774-6-git-send-email-steve.capper@linaro.org
State Superseded
Headers show

Commit Message

Steve Capper May 8, 2013, 9:52 a.m. UTC
All Transparent Huge Pages are allocated by the buddy allocator.

A compile time check is in place that fails when the order of a
transparent huge page is too large to be allocated by the buddy
allocator. Unfortunately that compile time check passes when:
HPAGE_PMD_ORDER == MAX_ORDER
( which is incorrect as the buddy allocator can only allocate
memory of order strictly less than MAX_ORDER. )

This patch updates the compile time check to fail in the above
case.

Signed-off-by: Steve Capper <steve.capper@linaro.org>
---
 include/linux/huge_mm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Steve Capper May 8, 2013, 12:03 p.m. UTC | #1
On Wed, May 08, 2013 at 03:44:17PM +0300, Kirill A. Shutemov wrote:
> On Wed, May 08, 2013 at 10:52:37AM +0100, Steve Capper wrote:
> > All Transparent Huge Pages are allocated by the buddy allocator.
> > 
> > A compile time check is in place that fails when the order of a
> > transparent huge page is too large to be allocated by the buddy
> > allocator. Unfortunately that compile time check passes when:
> > HPAGE_PMD_ORDER == MAX_ORDER
> > ( which is incorrect as the buddy allocator can only allocate
> > memory of order strictly less than MAX_ORDER. )
> 
> It looks confusing to me. Shouldn't we fix what MAX_ORDER means instead?
> 

It confused me as I originally had 13 as the order and couldn't
allocate any 512MB THPs :-).

MAX_ORDER appears to be used quite a lot so I think it would be
safer to change the use case here rather than its meaning.

Cheers,
Kirill A. Shutemov May 8, 2013, 12:44 p.m. UTC | #2
On Wed, May 08, 2013 at 10:52:37AM +0100, Steve Capper wrote:
> All Transparent Huge Pages are allocated by the buddy allocator.
> 
> A compile time check is in place that fails when the order of a
> transparent huge page is too large to be allocated by the buddy
> allocator. Unfortunately that compile time check passes when:
> HPAGE_PMD_ORDER == MAX_ORDER
> ( which is incorrect as the buddy allocator can only allocate
> memory of order strictly less than MAX_ORDER. )

It looks confusing to me. Shouldn't we fix what MAX_ORDER means instead?
diff mbox

Patch

diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index ee1c244..3d71e5c 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -119,7 +119,7 @@  extern void __split_huge_page_pmd(struct vm_area_struct *vma,
 	} while (0)
 extern void split_huge_page_pmd_mm(struct mm_struct *mm, unsigned long address,
 		pmd_t *pmd);
-#if HPAGE_PMD_ORDER > MAX_ORDER
+#if HPAGE_PMD_ORDER >= MAX_ORDER
 #error "hugepages can't be allocated by the buddy allocator"
 #endif
 extern int hugepage_madvise(struct vm_area_struct *vma,