All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH V2] mm: Some arch may want to use HPAGE_PMD related values as variables
@ 2016-02-09 16:11 ` Aneesh Kumar K.V
  0 siblings, 0 replies; 12+ messages in thread
From: Aneesh Kumar K.V @ 2016-02-09 16:11 UTC (permalink / raw)
  To: akpm, mpe, Kirill A. Shutemov; +Cc: linux-mm, linux-kernel, Aneesh Kumar K.V

With next generation power processor, we are having a new mmu model
[1] that require us to maintain a different linux page table format.

Inorder to support both current and future ppc64 systems with a single
kernel we need to make sure kernel can select between different page
table format at runtime. With the new MMU (radix MMU) added, we will
have two different pmd hugepage size 16MB for hash model and 2MB for
Radix model. Hence make HPAGE_PMD related values as a variable.

[1] http://ibm.biz/power-isa3 (Needs registration).

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
 arch/powerpc/mm/pgtable_64.c |  7 +++++++
 include/linux/bug.h          |  9 +++++++++
 include/linux/huge_mm.h      |  3 ---
 mm/huge_memory.c             | 17 ++++++++++++++---
 4 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index c8a00da39969..80dd8e0d8322 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -818,6 +818,13 @@ pmd_t pmdp_huge_get_and_clear(struct mm_struct *mm,
 
 int has_transparent_hugepage(void)
 {
+
+	BUILD_BUG_ON_MSG((PMD_SHIFT - PAGE_SHIFT) >= MAX_ORDER,
+		"hugepages can't be allocated by the buddy allocator");
+
+	BUILD_BUG_ON_MSG((PMD_SHIFT - PAGE_SHIFT) < 2,
+			 "We need more than 2 pages to do deferred thp split");
+
 	if (!mmu_has_feature(MMU_FTR_16M_PAGE))
 		return 0;
 	/*
diff --git a/include/linux/bug.h b/include/linux/bug.h
index 7f4818673c41..e51b0709e78d 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -20,6 +20,7 @@ struct pt_regs;
 #define BUILD_BUG_ON_MSG(cond, msg) (0)
 #define BUILD_BUG_ON(condition) (0)
 #define BUILD_BUG() (0)
+#define MAYBE_BUILD_BUG_ON(cond) (0)
 #else /* __CHECKER__ */
 
 /* Force a compilation error if a constant expression is not a power of 2 */
@@ -83,6 +84,14 @@ struct pt_regs;
  */
 #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
 
+#define MAYBE_BUILD_BUG_ON(cond)			\
+	do {						\
+		if (__builtin_constant_p((cond)))       \
+			BUILD_BUG_ON(cond);             \
+		else                                    \
+			BUG_ON(cond);                   \
+	} while (0)
+
 #endif	/* __CHECKER__ */
 
 #ifdef CONFIG_GENERIC_BUG
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 459fd25b378e..f12513a20a06 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -111,9 +111,6 @@ void __split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
 			__split_huge_pmd(__vma, __pmd, __address);	\
 	}  while (0)
 
-#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,
 			    unsigned long *vm_flags, int advice);
 extern void vma_adjust_trans_huge(struct vm_area_struct *vma,
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index cd26f3f14cab..350410e9019e 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -83,7 +83,7 @@ unsigned long transparent_hugepage_flags __read_mostly =
 	(1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG);
 
 /* default scan 8*512 pte (or vmas) every 30 second */
-static unsigned int khugepaged_pages_to_scan __read_mostly = HPAGE_PMD_NR*8;
+static unsigned int khugepaged_pages_to_scan __read_mostly;
 static unsigned int khugepaged_pages_collapsed;
 static unsigned int khugepaged_full_scans;
 static unsigned int khugepaged_scan_sleep_millisecs __read_mostly = 10000;
@@ -98,7 +98,7 @@ static DECLARE_WAIT_QUEUE_HEAD(khugepaged_wait);
  * it would have happened if the vma was large enough during page
  * fault.
  */
-static unsigned int khugepaged_max_ptes_none __read_mostly = HPAGE_PMD_NR-1;
+static unsigned int khugepaged_max_ptes_none __read_mostly;
 
 static int khugepaged(void *none);
 static int khugepaged_slab_init(void);
@@ -660,6 +660,18 @@ static int __init hugepage_init(void)
 		return -EINVAL;
 	}
 
+	khugepaged_pages_to_scan = HPAGE_PMD_NR * 8;
+	khugepaged_max_ptes_none = HPAGE_PMD_NR - 1;
+	/*
+	 * hugepages can't be allocated by the buddy allocator
+	 */
+	MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER >= MAX_ORDER);
+	/*
+	 * we use page->mapping and page->index in second tail page
+	 * as list_head: assuming THP order >= 2
+	 */
+	MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER < 2);
+
 	err = hugepage_init_sysfs(&hugepage_kobj);
 	if (err)
 		goto err_sysfs;
@@ -764,7 +776,6 @@ void prep_transhuge_page(struct page *page)
 	 * we use page->mapping and page->indexlru in second tail page
 	 * as list_head: assuming THP order >= 2
 	 */
-	BUILD_BUG_ON(HPAGE_PMD_ORDER < 2);
 
 	INIT_LIST_HEAD(page_deferred_list(page));
 	set_compound_page_dtor(page, TRANSHUGE_PAGE_DTOR);
-- 
2.5.0

^ permalink raw reply related	[flat|nested] 12+ messages in thread

* [PATCH V2] mm: Some arch may want to use HPAGE_PMD related values as variables
@ 2016-02-09 16:11 ` Aneesh Kumar K.V
  0 siblings, 0 replies; 12+ messages in thread
From: Aneesh Kumar K.V @ 2016-02-09 16:11 UTC (permalink / raw)
  To: akpm, mpe, Kirill A. Shutemov; +Cc: linux-mm, linux-kernel, Aneesh Kumar K.V

With next generation power processor, we are having a new mmu model
[1] that require us to maintain a different linux page table format.

Inorder to support both current and future ppc64 systems with a single
kernel we need to make sure kernel can select between different page
table format at runtime. With the new MMU (radix MMU) added, we will
have two different pmd hugepage size 16MB for hash model and 2MB for
Radix model. Hence make HPAGE_PMD related values as a variable.

[1] http://ibm.biz/power-isa3 (Needs registration).

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
 arch/powerpc/mm/pgtable_64.c |  7 +++++++
 include/linux/bug.h          |  9 +++++++++
 include/linux/huge_mm.h      |  3 ---
 mm/huge_memory.c             | 17 ++++++++++++++---
 4 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index c8a00da39969..80dd8e0d8322 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -818,6 +818,13 @@ pmd_t pmdp_huge_get_and_clear(struct mm_struct *mm,
 
 int has_transparent_hugepage(void)
 {
+
+	BUILD_BUG_ON_MSG((PMD_SHIFT - PAGE_SHIFT) >= MAX_ORDER,
+		"hugepages can't be allocated by the buddy allocator");
+
+	BUILD_BUG_ON_MSG((PMD_SHIFT - PAGE_SHIFT) < 2,
+			 "We need more than 2 pages to do deferred thp split");
+
 	if (!mmu_has_feature(MMU_FTR_16M_PAGE))
 		return 0;
 	/*
diff --git a/include/linux/bug.h b/include/linux/bug.h
index 7f4818673c41..e51b0709e78d 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -20,6 +20,7 @@ struct pt_regs;
 #define BUILD_BUG_ON_MSG(cond, msg) (0)
 #define BUILD_BUG_ON(condition) (0)
 #define BUILD_BUG() (0)
+#define MAYBE_BUILD_BUG_ON(cond) (0)
 #else /* __CHECKER__ */
 
 /* Force a compilation error if a constant expression is not a power of 2 */
@@ -83,6 +84,14 @@ struct pt_regs;
  */
 #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
 
+#define MAYBE_BUILD_BUG_ON(cond)			\
+	do {						\
+		if (__builtin_constant_p((cond)))       \
+			BUILD_BUG_ON(cond);             \
+		else                                    \
+			BUG_ON(cond);                   \
+	} while (0)
+
 #endif	/* __CHECKER__ */
 
 #ifdef CONFIG_GENERIC_BUG
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 459fd25b378e..f12513a20a06 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -111,9 +111,6 @@ void __split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
 			__split_huge_pmd(__vma, __pmd, __address);	\
 	}  while (0)
 
-#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,
 			    unsigned long *vm_flags, int advice);
 extern void vma_adjust_trans_huge(struct vm_area_struct *vma,
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index cd26f3f14cab..350410e9019e 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -83,7 +83,7 @@ unsigned long transparent_hugepage_flags __read_mostly =
 	(1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG);
 
 /* default scan 8*512 pte (or vmas) every 30 second */
-static unsigned int khugepaged_pages_to_scan __read_mostly = HPAGE_PMD_NR*8;
+static unsigned int khugepaged_pages_to_scan __read_mostly;
 static unsigned int khugepaged_pages_collapsed;
 static unsigned int khugepaged_full_scans;
 static unsigned int khugepaged_scan_sleep_millisecs __read_mostly = 10000;
@@ -98,7 +98,7 @@ static DECLARE_WAIT_QUEUE_HEAD(khugepaged_wait);
  * it would have happened if the vma was large enough during page
  * fault.
  */
-static unsigned int khugepaged_max_ptes_none __read_mostly = HPAGE_PMD_NR-1;
+static unsigned int khugepaged_max_ptes_none __read_mostly;
 
 static int khugepaged(void *none);
 static int khugepaged_slab_init(void);
@@ -660,6 +660,18 @@ static int __init hugepage_init(void)
 		return -EINVAL;
 	}
 
+	khugepaged_pages_to_scan = HPAGE_PMD_NR * 8;
+	khugepaged_max_ptes_none = HPAGE_PMD_NR - 1;
+	/*
+	 * hugepages can't be allocated by the buddy allocator
+	 */
+	MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER >= MAX_ORDER);
+	/*
+	 * we use page->mapping and page->index in second tail page
+	 * as list_head: assuming THP order >= 2
+	 */
+	MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER < 2);
+
 	err = hugepage_init_sysfs(&hugepage_kobj);
 	if (err)
 		goto err_sysfs;
@@ -764,7 +776,6 @@ void prep_transhuge_page(struct page *page)
 	 * we use page->mapping and page->indexlru in second tail page
 	 * as list_head: assuming THP order >= 2
 	 */
-	BUILD_BUG_ON(HPAGE_PMD_ORDER < 2);
 
 	INIT_LIST_HEAD(page_deferred_list(page));
 	set_compound_page_dtor(page, TRANSHUGE_PAGE_DTOR);
-- 
2.5.0

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

^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: [PATCH V2] mm: Some arch may want to use HPAGE_PMD related values as variables
  2016-02-09 16:11 ` Aneesh Kumar K.V
@ 2016-02-09 19:42   ` Kirill A. Shutemov
  -1 siblings, 0 replies; 12+ messages in thread
From: Kirill A. Shutemov @ 2016-02-09 19:42 UTC (permalink / raw)
  To: Aneesh Kumar K.V; +Cc: akpm, mpe, Kirill A. Shutemov, linux-mm, linux-kernel

On Tue, Feb 09, 2016 at 09:41:44PM +0530, Aneesh Kumar K.V wrote:
> With next generation power processor, we are having a new mmu model
> [1] that require us to maintain a different linux page table format.
> 
> Inorder to support both current and future ppc64 systems with a single
> kernel we need to make sure kernel can select between different page
> table format at runtime. With the new MMU (radix MMU) added, we will
> have two different pmd hugepage size 16MB for hash model and 2MB for
> Radix model. Hence make HPAGE_PMD related values as a variable.
> 
> [1] http://ibm.biz/power-isa3 (Needs registration).
> 
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

I guess it should have my signed-off-by ;)

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH V2] mm: Some arch may want to use HPAGE_PMD related values as variables
@ 2016-02-09 19:42   ` Kirill A. Shutemov
  0 siblings, 0 replies; 12+ messages in thread
From: Kirill A. Shutemov @ 2016-02-09 19:42 UTC (permalink / raw)
  To: Aneesh Kumar K.V; +Cc: akpm, mpe, Kirill A. Shutemov, linux-mm, linux-kernel

On Tue, Feb 09, 2016 at 09:41:44PM +0530, Aneesh Kumar K.V wrote:
> With next generation power processor, we are having a new mmu model
> [1] that require us to maintain a different linux page table format.
> 
> Inorder to support both current and future ppc64 systems with a single
> kernel we need to make sure kernel can select between different page
> table format at runtime. With the new MMU (radix MMU) added, we will
> have two different pmd hugepage size 16MB for hash model and 2MB for
> Radix model. Hence make HPAGE_PMD related values as a variable.
> 
> [1] http://ibm.biz/power-isa3 (Needs registration).
> 
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

I guess it should have my signed-off-by ;)

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

-- 
 Kirill A. Shutemov

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH V2] mm: Some arch may want to use HPAGE_PMD related values as variables
  2016-02-09 16:11 ` Aneesh Kumar K.V
@ 2016-02-09 21:26   ` Andrew Morton
  -1 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2016-02-09 21:26 UTC (permalink / raw)
  To: Aneesh Kumar K.V; +Cc: mpe, Kirill A. Shutemov, linux-mm, linux-kernel

On Tue,  9 Feb 2016 21:41:44 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:

> With next generation power processor, we are having a new mmu model
> [1] that require us to maintain a different linux page table format.
> 
> Inorder to support both current and future ppc64 systems with a single
> kernel we need to make sure kernel can select between different page
> table format at runtime. With the new MMU (radix MMU) added, we will
> have two different pmd hugepage size 16MB for hash model and 2MB for
> Radix model. Hence make HPAGE_PMD related values as a variable.
> 
> [1] http://ibm.biz/power-isa3 (Needs registration).
> 
> ...
>
> --- a/include/linux/bug.h
> +++ b/include/linux/bug.h
> @@ -20,6 +20,7 @@ struct pt_regs;
>  #define BUILD_BUG_ON_MSG(cond, msg) (0)
>  #define BUILD_BUG_ON(condition) (0)
>  #define BUILD_BUG() (0)
> +#define MAYBE_BUILD_BUG_ON(cond) (0)
>  #else /* __CHECKER__ */
>  
>  /* Force a compilation error if a constant expression is not a power of 2 */
> @@ -83,6 +84,14 @@ struct pt_regs;
>   */
>  #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
>  
> +#define MAYBE_BUILD_BUG_ON(cond)			\
> +	do {						\
> +		if (__builtin_constant_p((cond)))       \
> +			BUILD_BUG_ON(cond);             \
> +		else                                    \
> +			BUG_ON(cond);                   \
> +	} while (0)
> +

hm.  I suppose so.

> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -111,9 +111,6 @@ void __split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
>  			__split_huge_pmd(__vma, __pmd, __address);	\
>  	}  while (0)
>  
> -#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,
>  			    unsigned long *vm_flags, int advice);
>  extern void vma_adjust_trans_huge(struct vm_area_struct *vma,
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index cd26f3f14cab..350410e9019e 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -83,7 +83,7 @@ unsigned long transparent_hugepage_flags __read_mostly =
>  	(1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG);
>  
>  /* default scan 8*512 pte (or vmas) every 30 second */
> -static unsigned int khugepaged_pages_to_scan __read_mostly = HPAGE_PMD_NR*8;
> +static unsigned int khugepaged_pages_to_scan __read_mostly;
>  static unsigned int khugepaged_pages_collapsed;
>  static unsigned int khugepaged_full_scans;
>  static unsigned int khugepaged_scan_sleep_millisecs __read_mostly = 10000;
> @@ -98,7 +98,7 @@ static DECLARE_WAIT_QUEUE_HEAD(khugepaged_wait);
>   * it would have happened if the vma was large enough during page
>   * fault.
>   */
> -static unsigned int khugepaged_max_ptes_none __read_mostly = HPAGE_PMD_NR-1;
> +static unsigned int khugepaged_max_ptes_none __read_mostly;
>  
>  static int khugepaged(void *none);
>  static int khugepaged_slab_init(void);
> @@ -660,6 +660,18 @@ static int __init hugepage_init(void)
>  		return -EINVAL;
>  	}
>  
> +	khugepaged_pages_to_scan = HPAGE_PMD_NR * 8;
> +	khugepaged_max_ptes_none = HPAGE_PMD_NR - 1;

I don't understand this change.  We change the initialization from
at-compile-time to at-run-time, but nothing useful appears to have been
done.

> +	/*
> +	 * hugepages can't be allocated by the buddy allocator
> +	 */
> +	MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER >= MAX_ORDER);
> +	/*
> +	 * we use page->mapping and page->index in second tail page
> +	 * as list_head: assuming THP order >= 2
> +	 */
> +	MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER < 2);
> +
>  	err = hugepage_init_sysfs(&hugepage_kobj);
>  	if (err)
>  		goto err_sysfs;
>
> ...
>

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH V2] mm: Some arch may want to use HPAGE_PMD related values as variables
@ 2016-02-09 21:26   ` Andrew Morton
  0 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2016-02-09 21:26 UTC (permalink / raw)
  To: Aneesh Kumar K.V; +Cc: mpe, Kirill A. Shutemov, linux-mm, linux-kernel

On Tue,  9 Feb 2016 21:41:44 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:

> With next generation power processor, we are having a new mmu model
> [1] that require us to maintain a different linux page table format.
> 
> Inorder to support both current and future ppc64 systems with a single
> kernel we need to make sure kernel can select between different page
> table format at runtime. With the new MMU (radix MMU) added, we will
> have two different pmd hugepage size 16MB for hash model and 2MB for
> Radix model. Hence make HPAGE_PMD related values as a variable.
> 
> [1] http://ibm.biz/power-isa3 (Needs registration).
> 
> ...
>
> --- a/include/linux/bug.h
> +++ b/include/linux/bug.h
> @@ -20,6 +20,7 @@ struct pt_regs;
>  #define BUILD_BUG_ON_MSG(cond, msg) (0)
>  #define BUILD_BUG_ON(condition) (0)
>  #define BUILD_BUG() (0)
> +#define MAYBE_BUILD_BUG_ON(cond) (0)
>  #else /* __CHECKER__ */
>  
>  /* Force a compilation error if a constant expression is not a power of 2 */
> @@ -83,6 +84,14 @@ struct pt_regs;
>   */
>  #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
>  
> +#define MAYBE_BUILD_BUG_ON(cond)			\
> +	do {						\
> +		if (__builtin_constant_p((cond)))       \
> +			BUILD_BUG_ON(cond);             \
> +		else                                    \
> +			BUG_ON(cond);                   \
> +	} while (0)
> +

hm.  I suppose so.

> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -111,9 +111,6 @@ void __split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
>  			__split_huge_pmd(__vma, __pmd, __address);	\
>  	}  while (0)
>  
> -#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,
>  			    unsigned long *vm_flags, int advice);
>  extern void vma_adjust_trans_huge(struct vm_area_struct *vma,
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index cd26f3f14cab..350410e9019e 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -83,7 +83,7 @@ unsigned long transparent_hugepage_flags __read_mostly =
>  	(1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG);
>  
>  /* default scan 8*512 pte (or vmas) every 30 second */
> -static unsigned int khugepaged_pages_to_scan __read_mostly = HPAGE_PMD_NR*8;
> +static unsigned int khugepaged_pages_to_scan __read_mostly;
>  static unsigned int khugepaged_pages_collapsed;
>  static unsigned int khugepaged_full_scans;
>  static unsigned int khugepaged_scan_sleep_millisecs __read_mostly = 10000;
> @@ -98,7 +98,7 @@ static DECLARE_WAIT_QUEUE_HEAD(khugepaged_wait);
>   * it would have happened if the vma was large enough during page
>   * fault.
>   */
> -static unsigned int khugepaged_max_ptes_none __read_mostly = HPAGE_PMD_NR-1;
> +static unsigned int khugepaged_max_ptes_none __read_mostly;
>  
>  static int khugepaged(void *none);
>  static int khugepaged_slab_init(void);
> @@ -660,6 +660,18 @@ static int __init hugepage_init(void)
>  		return -EINVAL;
>  	}
>  
> +	khugepaged_pages_to_scan = HPAGE_PMD_NR * 8;
> +	khugepaged_max_ptes_none = HPAGE_PMD_NR - 1;

I don't understand this change.  We change the initialization from
at-compile-time to at-run-time, but nothing useful appears to have been
done.

> +	/*
> +	 * hugepages can't be allocated by the buddy allocator
> +	 */
> +	MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER >= MAX_ORDER);
> +	/*
> +	 * we use page->mapping and page->index in second tail page
> +	 * as list_head: assuming THP order >= 2
> +	 */
> +	MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER < 2);
> +
>  	err = hugepage_init_sysfs(&hugepage_kobj);
>  	if (err)
>  		goto err_sysfs;
>
> ...
>

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH V2] mm: Some arch may want to use HPAGE_PMD related values as variables
  2016-02-09 21:26   ` Andrew Morton
@ 2016-02-09 23:14     ` Kirill A. Shutemov
  -1 siblings, 0 replies; 12+ messages in thread
From: Kirill A. Shutemov @ 2016-02-09 23:14 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Aneesh Kumar K.V, mpe, Kirill A. Shutemov, linux-mm, linux-kernel

On Tue, Feb 09, 2016 at 01:26:08PM -0800, Andrew Morton wrote:
> On Tue,  9 Feb 2016 21:41:44 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> > @@ -660,6 +660,18 @@ static int __init hugepage_init(void)
> >  		return -EINVAL;
> >  	}
> >  
> > +	khugepaged_pages_to_scan = HPAGE_PMD_NR * 8;
> > +	khugepaged_max_ptes_none = HPAGE_PMD_NR - 1;
> 
> I don't understand this change.  We change the initialization from
> at-compile-time to at-run-time, but nothing useful appears to have been
> done.

It's preparation patch. HPAGE_PMD_NR is going to be based on variable on
Power soon. Compile-time is not an option.

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH V2] mm: Some arch may want to use HPAGE_PMD related values as variables
@ 2016-02-09 23:14     ` Kirill A. Shutemov
  0 siblings, 0 replies; 12+ messages in thread
From: Kirill A. Shutemov @ 2016-02-09 23:14 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Aneesh Kumar K.V, mpe, Kirill A. Shutemov, linux-mm, linux-kernel

On Tue, Feb 09, 2016 at 01:26:08PM -0800, Andrew Morton wrote:
> On Tue,  9 Feb 2016 21:41:44 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> > @@ -660,6 +660,18 @@ static int __init hugepage_init(void)
> >  		return -EINVAL;
> >  	}
> >  
> > +	khugepaged_pages_to_scan = HPAGE_PMD_NR * 8;
> > +	khugepaged_max_ptes_none = HPAGE_PMD_NR - 1;
> 
> I don't understand this change.  We change the initialization from
> at-compile-time to at-run-time, but nothing useful appears to have been
> done.

It's preparation patch. HPAGE_PMD_NR is going to be based on variable on
Power soon. Compile-time is not an option.

-- 
 Kirill A. Shutemov

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH V2] mm: Some arch may want to use HPAGE_PMD related values as variables
  2016-02-09 19:42   ` Kirill A. Shutemov
@ 2016-02-10  2:34     ` Aneesh Kumar K.V
  -1 siblings, 0 replies; 12+ messages in thread
From: Aneesh Kumar K.V @ 2016-02-10  2:34 UTC (permalink / raw)
  To: Kirill A. Shutemov; +Cc: akpm, mpe, Kirill A. Shutemov, linux-mm, linux-kernel

"Kirill A. Shutemov" <kirill@shutemov.name> writes:

> On Tue, Feb 09, 2016 at 09:41:44PM +0530, Aneesh Kumar K.V wrote:
>> With next generation power processor, we are having a new mmu model
>> [1] that require us to maintain a different linux page table format.
>> 
>> Inorder to support both current and future ppc64 systems with a single
>> kernel we need to make sure kernel can select between different page
>> table format at runtime. With the new MMU (radix MMU) added, we will
>> have two different pmd hugepage size 16MB for hash model and 2MB for
>> Radix model. Hence make HPAGE_PMD related values as a variable.
>> 
>> [1] http://ibm.biz/power-isa3 (Needs registration).
>> 
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>
> I guess it should have my signed-off-by ;)
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

Thanks will update. I will also update the From:

-aneesh

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH V2] mm: Some arch may want to use HPAGE_PMD related values as variables
@ 2016-02-10  2:34     ` Aneesh Kumar K.V
  0 siblings, 0 replies; 12+ messages in thread
From: Aneesh Kumar K.V @ 2016-02-10  2:34 UTC (permalink / raw)
  To: Kirill A. Shutemov; +Cc: akpm, mpe, Kirill A. Shutemov, linux-mm, linux-kernel

"Kirill A. Shutemov" <kirill@shutemov.name> writes:

> On Tue, Feb 09, 2016 at 09:41:44PM +0530, Aneesh Kumar K.V wrote:
>> With next generation power processor, we are having a new mmu model
>> [1] that require us to maintain a different linux page table format.
>> 
>> Inorder to support both current and future ppc64 systems with a single
>> kernel we need to make sure kernel can select between different page
>> table format at runtime. With the new MMU (radix MMU) added, we will
>> have two different pmd hugepage size 16MB for hash model and 2MB for
>> Radix model. Hence make HPAGE_PMD related values as a variable.
>> 
>> [1] http://ibm.biz/power-isa3 (Needs registration).
>> 
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>
> I guess it should have my signed-off-by ;)
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

Thanks will update. I will also update the From:

-aneesh

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH V2] mm: Some arch may want to use HPAGE_PMD related values as variables
  2016-02-09 21:26   ` Andrew Morton
@ 2016-02-10  2:39     ` Aneesh Kumar K.V
  -1 siblings, 0 replies; 12+ messages in thread
From: Aneesh Kumar K.V @ 2016-02-10  2:39 UTC (permalink / raw)
  To: Andrew Morton; +Cc: mpe, Kirill A. Shutemov, linux-mm, linux-kernel

Andrew Morton <akpm@linux-foundation.org> writes:

> On Tue,  9 Feb 2016 21:41:44 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
>
>> With next generation power processor, we are having a new mmu model
>> [1] that require us to maintain a different linux page table format.
>> 
>> Inorder to support both current and future ppc64 systems with a single
>> kernel we need to make sure kernel can select between different page
>> table format at runtime. With the new MMU (radix MMU) added, we will
>> have two different pmd hugepage size 16MB for hash model and 2MB for
>> Radix model. Hence make HPAGE_PMD related values as a variable.
>> 
>> [1] http://ibm.biz/power-isa3 (Needs registration).
>> 
>> ...
>>
>> --- a/include/linux/bug.h
>> +++ b/include/linux/bug.h
>> @@ -20,6 +20,7 @@ struct pt_regs;
>>  #define BUILD_BUG_ON_MSG(cond, msg) (0)
>>  #define BUILD_BUG_ON(condition) (0)
>>  #define BUILD_BUG() (0)
>> +#define MAYBE_BUILD_BUG_ON(cond) (0)
>>  #else /* __CHECKER__ */
>>  
>>  /* Force a compilation error if a constant expression is not a power of 2 */
>> @@ -83,6 +84,14 @@ struct pt_regs;
>>   */
>>  #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
>>  
>> +#define MAYBE_BUILD_BUG_ON(cond)			\
>> +	do {						\
>> +		if (__builtin_constant_p((cond)))       \
>> +			BUILD_BUG_ON(cond);             \
>> +		else                                    \
>> +			BUG_ON(cond);                   \
>> +	} while (0)
>> +
>
> hm.  I suppose so.
>
>> --- a/include/linux/huge_mm.h
>> +++ b/include/linux/huge_mm.h
>> @@ -111,9 +111,6 @@ void __split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
>>  			__split_huge_pmd(__vma, __pmd, __address);	\
>>  	}  while (0)
>>  
>> -#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,
>>  			    unsigned long *vm_flags, int advice);
>>  extern void vma_adjust_trans_huge(struct vm_area_struct *vma,
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index cd26f3f14cab..350410e9019e 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -83,7 +83,7 @@ unsigned long transparent_hugepage_flags __read_mostly =
>>  	(1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG);
>>  
>>  /* default scan 8*512 pte (or vmas) every 30 second */
>> -static unsigned int khugepaged_pages_to_scan __read_mostly = HPAGE_PMD_NR*8;
>> +static unsigned int khugepaged_pages_to_scan __read_mostly;
>>  static unsigned int khugepaged_pages_collapsed;
>>  static unsigned int khugepaged_full_scans;
>>  static unsigned int khugepaged_scan_sleep_millisecs __read_mostly = 10000;
>> @@ -98,7 +98,7 @@ static DECLARE_WAIT_QUEUE_HEAD(khugepaged_wait);
>>   * it would have happened if the vma was large enough during page
>>   * fault.
>>   */
>> -static unsigned int khugepaged_max_ptes_none __read_mostly = HPAGE_PMD_NR-1;
>> +static unsigned int khugepaged_max_ptes_none __read_mostly;
>>  
>>  static int khugepaged(void *none);
>>  static int khugepaged_slab_init(void);
>> @@ -660,6 +660,18 @@ static int __init hugepage_init(void)
>>  		return -EINVAL;
>>  	}
>>  
>> +	khugepaged_pages_to_scan = HPAGE_PMD_NR * 8;
>> +	khugepaged_max_ptes_none = HPAGE_PMD_NR - 1;
>
> I don't understand this change.  We change the initialization from
> at-compile-time to at-run-time, but nothing useful appears to have been
> done.
>

The related changes are in another series, 
https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-February/thread.html#138948

I would also like to keep the two core mm patches[1] in that series so that
it can go with the other related changes via powerpc tree. The reason to
send out them as separate patches is to get the correct feedback so that
it won't get lost in the large series.

Let me know if that is ok with you.

[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-February/138955.html
    https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-February/138964.html

-aneesh

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH V2] mm: Some arch may want to use HPAGE_PMD related values as variables
@ 2016-02-10  2:39     ` Aneesh Kumar K.V
  0 siblings, 0 replies; 12+ messages in thread
From: Aneesh Kumar K.V @ 2016-02-10  2:39 UTC (permalink / raw)
  To: Andrew Morton; +Cc: mpe, Kirill A. Shutemov, linux-mm, linux-kernel

Andrew Morton <akpm@linux-foundation.org> writes:

> On Tue,  9 Feb 2016 21:41:44 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
>
>> With next generation power processor, we are having a new mmu model
>> [1] that require us to maintain a different linux page table format.
>> 
>> Inorder to support both current and future ppc64 systems with a single
>> kernel we need to make sure kernel can select between different page
>> table format at runtime. With the new MMU (radix MMU) added, we will
>> have two different pmd hugepage size 16MB for hash model and 2MB for
>> Radix model. Hence make HPAGE_PMD related values as a variable.
>> 
>> [1] http://ibm.biz/power-isa3 (Needs registration).
>> 
>> ...
>>
>> --- a/include/linux/bug.h
>> +++ b/include/linux/bug.h
>> @@ -20,6 +20,7 @@ struct pt_regs;
>>  #define BUILD_BUG_ON_MSG(cond, msg) (0)
>>  #define BUILD_BUG_ON(condition) (0)
>>  #define BUILD_BUG() (0)
>> +#define MAYBE_BUILD_BUG_ON(cond) (0)
>>  #else /* __CHECKER__ */
>>  
>>  /* Force a compilation error if a constant expression is not a power of 2 */
>> @@ -83,6 +84,14 @@ struct pt_regs;
>>   */
>>  #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
>>  
>> +#define MAYBE_BUILD_BUG_ON(cond)			\
>> +	do {						\
>> +		if (__builtin_constant_p((cond)))       \
>> +			BUILD_BUG_ON(cond);             \
>> +		else                                    \
>> +			BUG_ON(cond);                   \
>> +	} while (0)
>> +
>
> hm.  I suppose so.
>
>> --- a/include/linux/huge_mm.h
>> +++ b/include/linux/huge_mm.h
>> @@ -111,9 +111,6 @@ void __split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
>>  			__split_huge_pmd(__vma, __pmd, __address);	\
>>  	}  while (0)
>>  
>> -#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,
>>  			    unsigned long *vm_flags, int advice);
>>  extern void vma_adjust_trans_huge(struct vm_area_struct *vma,
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index cd26f3f14cab..350410e9019e 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -83,7 +83,7 @@ unsigned long transparent_hugepage_flags __read_mostly =
>>  	(1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG);
>>  
>>  /* default scan 8*512 pte (or vmas) every 30 second */
>> -static unsigned int khugepaged_pages_to_scan __read_mostly = HPAGE_PMD_NR*8;
>> +static unsigned int khugepaged_pages_to_scan __read_mostly;
>>  static unsigned int khugepaged_pages_collapsed;
>>  static unsigned int khugepaged_full_scans;
>>  static unsigned int khugepaged_scan_sleep_millisecs __read_mostly = 10000;
>> @@ -98,7 +98,7 @@ static DECLARE_WAIT_QUEUE_HEAD(khugepaged_wait);
>>   * it would have happened if the vma was large enough during page
>>   * fault.
>>   */
>> -static unsigned int khugepaged_max_ptes_none __read_mostly = HPAGE_PMD_NR-1;
>> +static unsigned int khugepaged_max_ptes_none __read_mostly;
>>  
>>  static int khugepaged(void *none);
>>  static int khugepaged_slab_init(void);
>> @@ -660,6 +660,18 @@ static int __init hugepage_init(void)
>>  		return -EINVAL;
>>  	}
>>  
>> +	khugepaged_pages_to_scan = HPAGE_PMD_NR * 8;
>> +	khugepaged_max_ptes_none = HPAGE_PMD_NR - 1;
>
> I don't understand this change.  We change the initialization from
> at-compile-time to at-run-time, but nothing useful appears to have been
> done.
>

The related changes are in another series, 
https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-February/thread.html#138948

I would also like to keep the two core mm patches[1] in that series so that
it can go with the other related changes via powerpc tree. The reason to
send out them as separate patches is to get the correct feedback so that
it won't get lost in the large series.

Let me know if that is ok with you.

[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-February/138955.html
    https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-February/138964.html

-aneesh

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2016-02-10  2:39 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-09 16:11 [PATCH V2] mm: Some arch may want to use HPAGE_PMD related values as variables Aneesh Kumar K.V
2016-02-09 16:11 ` Aneesh Kumar K.V
2016-02-09 19:42 ` Kirill A. Shutemov
2016-02-09 19:42   ` Kirill A. Shutemov
2016-02-10  2:34   ` Aneesh Kumar K.V
2016-02-10  2:34     ` Aneesh Kumar K.V
2016-02-09 21:26 ` Andrew Morton
2016-02-09 21:26   ` Andrew Morton
2016-02-09 23:14   ` Kirill A. Shutemov
2016-02-09 23:14     ` Kirill A. Shutemov
2016-02-10  2:39   ` Aneesh Kumar K.V
2016-02-10  2:39     ` Aneesh Kumar K.V

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.