lkml.org 
[lkml]   [2016]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH V2] mm: Some arch may want to use HPAGE_PMD related values as variables
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;
>
> ...
>

\
 
 \ /
  Last update: 2016-02-09 22:41    [W:0.082 / U:3.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site