| Message ID | 1368006763-30774-6-git-send-email-steve.capper@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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,
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 --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,
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(-)