* [PATCH v2 1/2] mm/hugetlb: Allow arch to override and call the weak function @ 2017-06-01 14:30 Aneesh Kumar K.V 2017-06-01 14:30 ` [PATCH v2 2/2] powerpc/mm/hugetlb: Add support for reserving gigantic huge pages via kernel command line Aneesh Kumar K.V 0 siblings, 1 reply; 8+ messages in thread From: Aneesh Kumar K.V @ 2017-06-01 14:30 UTC (permalink / raw) To: benh, paulus, mpe; +Cc: linuxppc-dev, Aneesh Kumar K.V For ppc64, we want to call this function when we are not running as guest. Also, if we failed to allocate hugepages, let the user know. Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- include/linux/hugetlb.h | 1 + mm/hugetlb.c | 5 ++++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index caee7c4664c8..964401ff0af0 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -357,6 +357,7 @@ int huge_add_to_page_cache(struct page *page, struct address_space *mapping, pgoff_t idx); /* arch callback */ +int __init __alloc_bootmem_huge_page(struct hstate *h); int __init alloc_bootmem_huge_page(struct hstate *h); void __init hugetlb_bad_size(void); diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 28217a147fe3..160282b13722 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -2103,7 +2103,9 @@ struct page *alloc_huge_page_noerr(struct vm_area_struct *vma, return page; } -int __weak alloc_bootmem_huge_page(struct hstate *h) +int alloc_bootmem_huge_page(struct hstate *h) + __attribute__ ((weak, alias("__alloc_bootmem_huge_page"))); +int __alloc_bootmem_huge_page(struct hstate *h) { struct huge_bootmem_page *m; int nr_nodes, node; @@ -2124,6 +2126,7 @@ int __weak alloc_bootmem_huge_page(struct hstate *h) goto found; } } + pr_info("Failed to allocate hugepage of size %ld\n", huge_page_size(h)); return 0; found: -- 2.7.4 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH v2 2/2] powerpc/mm/hugetlb: Add support for reserving gigantic huge pages via kernel command line 2017-06-01 14:30 [PATCH v2 1/2] mm/hugetlb: Allow arch to override and call the weak function Aneesh Kumar K.V @ 2017-06-01 14:30 ` Aneesh Kumar K.V 2017-06-01 16:42 ` christophe leroy 0 siblings, 1 reply; 8+ messages in thread From: Aneesh Kumar K.V @ 2017-06-01 14:30 UTC (permalink / raw) To: benh, paulus, mpe Cc: linuxppc-dev, Aneesh Kumar K.V, Scott Wood, Christophe Leroy With commit aa888a74977a8 ("hugetlb: support larger than MAX_ORDER") we added support for allocating gigantic hugepages via kernel command line. Switch ppc64 arch specific code to use that. W.r.t FSL support, we now limit our allocation range using BOOTMEM_ALLOC_ACCESSIBLE. We use the kernel command line to do reservation of hugetlb pages on powernv platforms. On pseries hash mmu mode the supported gigantic huge page size is 16GB and that can only be allocated with hypervisor assist. For pseries the command line option doesn't do the allocation. Instead pseries does gigantic hugepage allocation based on hypervisor hint that is specified via "ibm,expected#pages" property of the memory node. Cc: Scott Wood <oss@buserror.net> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- arch/powerpc/include/asm/book3s/64/mmu-hash.h | 2 +- arch/powerpc/include/asm/hugetlb.h | 14 -- arch/powerpc/kernel/setup-common.c | 7 - arch/powerpc/mm/hash_utils_64.c | 2 +- arch/powerpc/mm/hugetlbpage.c | 177 +++----------------------- arch/powerpc/mm/init_32.c | 2 - 6 files changed, 22 insertions(+), 182 deletions(-) diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h b/arch/powerpc/include/asm/book3s/64/mmu-hash.h index 6981a52b3887..67766e60a6b6 100644 --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h @@ -468,7 +468,7 @@ extern int htab_bolt_mapping(unsigned long vstart, unsigned long vend, int psize, int ssize); int htab_remove_mapping(unsigned long vstart, unsigned long vend, int psize, int ssize); -extern void add_gpage(u64 addr, u64 page_size, unsigned long number_of_pages); +extern void pSeries_add_gpage(u64 addr, u64 page_size, unsigned long number_of_pages); extern void demote_segment_4k(struct mm_struct *mm, unsigned long addr); #ifdef CONFIG_PPC_PSERIES diff --git a/arch/powerpc/include/asm/hugetlb.h b/arch/powerpc/include/asm/hugetlb.h index 7f4025a6c69e..b8a0fb442c64 100644 --- a/arch/powerpc/include/asm/hugetlb.h +++ b/arch/powerpc/include/asm/hugetlb.h @@ -218,18 +218,4 @@ static inline pte_t *hugepte_offset(hugepd_t hpd, unsigned long addr, } #endif /* CONFIG_HUGETLB_PAGE */ -/* - * FSL Book3E platforms require special gpage handling - the gpages - * are reserved early in the boot process by memblock instead of via - * the .dts as on IBM platforms. - */ -#if defined(CONFIG_HUGETLB_PAGE) && (defined(CONFIG_PPC_FSL_BOOK3E) || \ - defined(CONFIG_PPC_8xx)) -extern void __init reserve_hugetlb_gpages(void); -#else -static inline void reserve_hugetlb_gpages(void) -{ -} -#endif - #endif /* _ASM_POWERPC_HUGETLB_H */ diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c index 71dcda91755d..8389ff5ac002 100644 --- a/arch/powerpc/kernel/setup-common.c +++ b/arch/powerpc/kernel/setup-common.c @@ -912,13 +912,6 @@ void __init setup_arch(char **cmdline_p) /* Reserve large chunks of memory for use by CMA for KVM. */ kvm_cma_reserve(); - /* - * Reserve any gigantic pages requested on the command line. - * memblock needs to have been initialized by the time this is - * called since this will reserve memory. - */ - reserve_hugetlb_gpages(); - klp_init_thread_info(&init_thread_info); init_mm.start_code = (unsigned long)_stext; diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c index f2095ce9d4b0..c4b04c4aac86 100644 --- a/arch/powerpc/mm/hash_utils_64.c +++ b/arch/powerpc/mm/hash_utils_64.c @@ -509,7 +509,7 @@ static int __init htab_dt_scan_hugepage_blocks(unsigned long node, phys_addr, block_size, expected_pages); if (phys_addr + (16 * GB) <= memblock_end_of_DRAM()) { memblock_reserve(phys_addr, block_size * expected_pages); - add_gpage(phys_addr, block_size, expected_pages); + pSeries_add_gpage(phys_addr, block_size, expected_pages); } return 0; } diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c index 1816b965a142..2bcb7e5b2ab6 100644 --- a/arch/powerpc/mm/hugetlbpage.c +++ b/arch/powerpc/mm/hugetlbpage.c @@ -35,26 +35,6 @@ unsigned int HPAGE_SHIFT; -/* - * Tracks gpages after the device tree is scanned and before the - * huge_boot_pages list is ready. On non-Freescale implementations, this is - * just used to track 16G pages and so is a single array. FSL-based - * implementations may have more than one gpage size, so we need multiple - * arrays - */ -#if defined(CONFIG_PPC_FSL_BOOK3E) || defined(CONFIG_PPC_8xx) -#define MAX_NUMBER_GPAGES 128 -struct psize_gpages { - u64 gpage_list[MAX_NUMBER_GPAGES]; - unsigned int nr_gpages; -}; -static struct psize_gpages gpage_freearray[MMU_PAGE_COUNT]; -#else -#define MAX_NUMBER_GPAGES 1024 -static u64 gpage_freearray[MAX_NUMBER_GPAGES]; -static unsigned nr_gpages; -#endif - #define hugepd_none(hpd) (hpd_val(hpd) == 0) pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr) @@ -209,145 +189,20 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long addr, unsigned long sz return hugepte_offset(*hpdp, addr, pdshift); } -#if defined(CONFIG_PPC_FSL_BOOK3E) || defined(CONFIG_PPC_8xx) -/* Build list of addresses of gigantic pages. This function is used in early - * boot before the buddy allocator is setup. - */ -void add_gpage(u64 addr, u64 page_size, unsigned long number_of_pages) -{ - unsigned int idx = shift_to_mmu_psize(__ffs(page_size)); - int i; - - if (addr == 0) - return; - - gpage_freearray[idx].nr_gpages = number_of_pages; - - for (i = 0; i < number_of_pages; i++) { - gpage_freearray[idx].gpage_list[i] = addr; - addr += page_size; - } -} - -/* - * Moves the gigantic page addresses from the temporary list to the - * huge_boot_pages list. - */ -int alloc_bootmem_huge_page(struct hstate *hstate) -{ - struct huge_bootmem_page *m; - int idx = shift_to_mmu_psize(huge_page_shift(hstate)); - int nr_gpages = gpage_freearray[idx].nr_gpages; - - if (nr_gpages == 0) - return 0; - -#ifdef CONFIG_HIGHMEM - /* - * If gpages can be in highmem we can't use the trick of storing the - * data structure in the page; allocate space for this - */ - m = memblock_virt_alloc(sizeof(struct huge_bootmem_page), 0); - m->phys = gpage_freearray[idx].gpage_list[--nr_gpages]; -#else - m = phys_to_virt(gpage_freearray[idx].gpage_list[--nr_gpages]); -#endif - - list_add(&m->list, &huge_boot_pages); - gpage_freearray[idx].nr_gpages = nr_gpages; - gpage_freearray[idx].gpage_list[nr_gpages] = 0; - m->hstate = hstate; - - return 1; -} +#ifdef CONFIG_PPC_BOOK3S_64 /* - * Scan the command line hugepagesz= options for gigantic pages; store those in - * a list that we use to allocate the memory once all options are parsed. + * Tracks gpages after the device tree is scanned and before the + * huge_boot_pages list is ready on pSeries. */ - -unsigned long gpage_npages[MMU_PAGE_COUNT]; - -static int __init do_gpage_early_setup(char *param, char *val, - const char *unused, void *arg) -{ - static phys_addr_t size; - unsigned long npages; - - /* - * The hugepagesz and hugepages cmdline options are interleaved. We - * use the size variable to keep track of whether or not this was done - * properly and skip over instances where it is incorrect. Other - * command-line parsing code will issue warnings, so we don't need to. - * - */ - if ((strcmp(param, "default_hugepagesz") == 0) || - (strcmp(param, "hugepagesz") == 0)) { - size = memparse(val, NULL); - } else if (strcmp(param, "hugepages") == 0) { - if (size != 0) { - if (sscanf(val, "%lu", &npages) <= 0) - npages = 0; - if (npages > MAX_NUMBER_GPAGES) { - pr_warn("MMU: %lu pages requested for page " -#ifdef CONFIG_PHYS_ADDR_T_64BIT - "size %llu KB, limiting to " -#else - "size %u KB, limiting to " -#endif - __stringify(MAX_NUMBER_GPAGES) "\n", - npages, size / 1024); - npages = MAX_NUMBER_GPAGES; - } - gpage_npages[shift_to_mmu_psize(__ffs(size))] = npages; - size = 0; - } - } - return 0; -} - +#define MAX_NUMBER_GPAGES 1024 +__initdata static u64 gpage_freearray[MAX_NUMBER_GPAGES]; +__initdata static unsigned nr_gpages; /* - * This function allocates physical space for pages that are larger than the - * buddy allocator can handle. We want to allocate these in highmem because - * the amount of lowmem is limited. This means that this function MUST be - * called before lowmem_end_addr is set up in MMU_init() in order for the lmb - * allocate to grab highmem. - */ -void __init reserve_hugetlb_gpages(void) -{ - static __initdata char cmdline[COMMAND_LINE_SIZE]; - phys_addr_t size, base; - int i; - - strlcpy(cmdline, boot_command_line, COMMAND_LINE_SIZE); - parse_args("hugetlb gpages", cmdline, NULL, 0, 0, 0, - NULL, &do_gpage_early_setup); - - /* - * Walk gpage list in reverse, allocating larger page sizes first. - * Skip over unsupported sizes, or sizes that have 0 gpages allocated. - * When we reach the point in the list where pages are no longer - * considered gpages, we're done. - */ - for (i = MMU_PAGE_COUNT-1; i >= 0; i--) { - if (mmu_psize_defs[i].shift == 0 || gpage_npages[i] == 0) - continue; - else if (mmu_psize_to_shift(i) < (MAX_ORDER + PAGE_SHIFT)) - break; - - size = (phys_addr_t)(1ULL << mmu_psize_to_shift(i)); - base = memblock_alloc_base(size * gpage_npages[i], size, - MEMBLOCK_ALLOC_ANYWHERE); - add_gpage(base, size, gpage_npages[i]); - } -} - -#else /* !PPC_FSL_BOOK3E */ - -/* Build list of addresses of gigantic pages. This function is used in early + * Build list of addresses of gigantic pages. This function is used in early * boot before the buddy allocator is setup. */ -void add_gpage(u64 addr, u64 page_size, unsigned long number_of_pages) +void __init pSeries_add_gpage(u64 addr, u64 page_size, unsigned long number_of_pages) { if (!addr) return; @@ -359,10 +214,7 @@ void add_gpage(u64 addr, u64 page_size, unsigned long number_of_pages) } } -/* Moves the gigantic page addresses from the temporary list to the - * huge_boot_pages list. - */ -int alloc_bootmem_huge_page(struct hstate *hstate) +int __init pSeries_alloc_bootmem_huge_page(struct hstate *hstate) { struct huge_bootmem_page *m; if (nr_gpages == 0) @@ -375,6 +227,17 @@ int alloc_bootmem_huge_page(struct hstate *hstate) } #endif + +int __init alloc_bootmem_huge_page(struct hstate *h) +{ + +#ifdef CONFIG_PPC_BOOK3S_64 + if (firmware_has_feature(FW_FEATURE_LPAR) && !radix_enabled()) + return pSeries_alloc_bootmem_huge_page(h); +#endif + return __alloc_bootmem_huge_page(h); +} + #if defined(CONFIG_PPC_FSL_BOOK3E) || defined(CONFIG_PPC_8xx) #define HUGEPD_FREELIST_SIZE \ ((PAGE_SIZE - sizeof(struct hugepd_freelist)) / sizeof(pte_t)) diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c index 8a7c38b8d335..436d9721ab63 100644 --- a/arch/powerpc/mm/init_32.c +++ b/arch/powerpc/mm/init_32.c @@ -132,8 +132,6 @@ void __init MMU_init(void) * Reserve gigantic pages for hugetlb. This MUST occur before * lowmem_end_addr is initialized below. */ - reserve_hugetlb_gpages(); - if (memblock.memory.cnt > 1) { #ifndef CONFIG_WII memblock_enforce_memory_limit(memblock.memory.regions[0].size); -- 2.7.4 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH v2 2/2] powerpc/mm/hugetlb: Add support for reserving gigantic huge pages via kernel command line 2017-06-01 14:30 ` [PATCH v2 2/2] powerpc/mm/hugetlb: Add support for reserving gigantic huge pages via kernel command line Aneesh Kumar K.V @ 2017-06-01 16:42 ` christophe leroy 2017-06-01 19:11 ` Tyrel Datwyler 2017-06-05 7:47 ` Aneesh Kumar K.V 0 siblings, 2 replies; 8+ messages in thread From: christophe leroy @ 2017-06-01 16:42 UTC (permalink / raw) To: Aneesh Kumar K.V, benh, paulus, mpe; +Cc: linuxppc-dev, Scott Wood Le 01/06/2017 à 16:30, Aneesh Kumar K.V a écrit : > With commit aa888a74977a8 ("hugetlb: support larger than MAX_ORDER") we added > support for allocating gigantic hugepages via kernel command line. Switch > ppc64 arch specific code to use that. Is it only ppc64 ? Your patch removes things defined for the 8xx and modifies stuff in init_32.c On the 8xx, as far as I remember, 8M pages on 4k pages mode are above default MAX_ORDER, I solved it by increasing MAX_ORDER. Is that wrong ? > > W.r.t FSL support, we now limit our allocation range using BOOTMEM_ALLOC_ACCESSIBLE. > > We use the kernel command line to do reservation of hugetlb pages on powernv > platforms. On pseries hash mmu mode the supported gigantic huge page size is > 16GB and that can only be allocated with hypervisor assist. For pseries the > command line option doesn't do the allocation. Instead pseries does gigantic > hugepage allocation based on hypervisor hint that is specified via > "ibm,expected#pages" property of the memory node. > > Cc: Scott Wood <oss@buserror.net> > Cc: Christophe Leroy <christophe.leroy@c-s.fr> > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> > --- > arch/powerpc/include/asm/book3s/64/mmu-hash.h | 2 +- > arch/powerpc/include/asm/hugetlb.h | 14 -- > arch/powerpc/kernel/setup-common.c | 7 - > arch/powerpc/mm/hash_utils_64.c | 2 +- > arch/powerpc/mm/hugetlbpage.c | 177 +++----------------------- > arch/powerpc/mm/init_32.c | 2 - > 6 files changed, 22 insertions(+), 182 deletions(-) > > diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h b/arch/powerpc/include/asm/book3s/64/mmu-hash.h > index 6981a52b3887..67766e60a6b6 100644 > --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h > +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h > @@ -468,7 +468,7 @@ extern int htab_bolt_mapping(unsigned long vstart, unsigned long vend, > int psize, int ssize); > int htab_remove_mapping(unsigned long vstart, unsigned long vend, > int psize, int ssize); > -extern void add_gpage(u64 addr, u64 page_size, unsigned long number_of_pages); > +extern void pSeries_add_gpage(u64 addr, u64 page_size, unsigned long number_of_pages); Linux kernel coding style says 'mixed-case names are frowned upon' Christophe --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2 2/2] powerpc/mm/hugetlb: Add support for reserving gigantic huge pages via kernel command line 2017-06-01 16:42 ` christophe leroy @ 2017-06-01 19:11 ` Tyrel Datwyler 2017-06-02 3:03 ` Michael Ellerman 2017-06-05 7:47 ` Aneesh Kumar K.V 1 sibling, 1 reply; 8+ messages in thread From: Tyrel Datwyler @ 2017-06-01 19:11 UTC (permalink / raw) To: christophe leroy, Aneesh Kumar K.V, benh, paulus, mpe Cc: Scott Wood, linuxppc-dev On 06/01/2017 09:42 AM, christophe leroy wrote: > > > Le 01/06/2017 à 16:30, Aneesh Kumar K.V a écrit : >> With commit aa888a74977a8 ("hugetlb: support larger than MAX_ORDER") we added >> support for allocating gigantic hugepages via kernel command line. Switch >> ppc64 arch specific code to use that. > > Is it only ppc64 ? Your patch removes things defined for the 8xx and > modifies stuff in init_32.c > > On the 8xx, as far as I remember, 8M pages on 4k pages mode are above > default MAX_ORDER, I solved it by increasing MAX_ORDER. Is that wrong ? > >> >> W.r.t FSL support, we now limit our allocation range using BOOTMEM_ALLOC_ACCESSIBLE. >> >> We use the kernel command line to do reservation of hugetlb pages on powernv >> platforms. On pseries hash mmu mode the supported gigantic huge page size is >> 16GB and that can only be allocated with hypervisor assist. For pseries the >> command line option doesn't do the allocation. Instead pseries does gigantic >> hugepage allocation based on hypervisor hint that is specified via >> "ibm,expected#pages" property of the memory node. >> >> Cc: Scott Wood <oss@buserror.net> >> Cc: Christophe Leroy <christophe.leroy@c-s.fr> >> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> >> --- >> arch/powerpc/include/asm/book3s/64/mmu-hash.h | 2 +- >> arch/powerpc/include/asm/hugetlb.h | 14 -- >> arch/powerpc/kernel/setup-common.c | 7 - >> arch/powerpc/mm/hash_utils_64.c | 2 +- >> arch/powerpc/mm/hugetlbpage.c | 177 +++----------------------- >> arch/powerpc/mm/init_32.c | 2 - >> 6 files changed, 22 insertions(+), 182 deletions(-) >> >> diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h b/arch/powerpc/include/asm/book3s/64/mmu-hash.h >> index 6981a52b3887..67766e60a6b6 100644 >> --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h >> +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h >> @@ -468,7 +468,7 @@ extern int htab_bolt_mapping(unsigned long vstart, unsigned long vend, >> int psize, int ssize); >> int htab_remove_mapping(unsigned long vstart, unsigned long vend, >> int psize, int ssize); >> -extern void add_gpage(u64 addr, u64 page_size, unsigned long number_of_pages); >> +extern void pSeries_add_gpage(u64 addr, u64 page_size, unsigned long number_of_pages); > > Linux kernel coding style says 'mixed-case names are frowned upon' True, but there is precedent within arch/powerpc/platforms/pseries seeing as "pSeries_" is already used heavily to prefix function names. -Tyrel > > Christophe > > --- > L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. > https://www.avast.com/antivirus > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2 2/2] powerpc/mm/hugetlb: Add support for reserving gigantic huge pages via kernel command line 2017-06-01 19:11 ` Tyrel Datwyler @ 2017-06-02 3:03 ` Michael Ellerman 2017-06-05 7:47 ` Aneesh Kumar K.V 0 siblings, 1 reply; 8+ messages in thread From: Michael Ellerman @ 2017-06-02 3:03 UTC (permalink / raw) To: Tyrel Datwyler, christophe leroy, Aneesh Kumar K.V, benh, paulus Cc: Scott Wood, linuxppc-dev Tyrel Datwyler <tyreld@linux.vnet.ibm.com> writes: > On 06/01/2017 09:42 AM, christophe leroy wrote: >> Le 01/06/2017 =C3=A0 16:30, Aneesh Kumar K.V a =C3=A9crit : >>> diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h b/arch/power= pc/include/asm/book3s/64/mmu-hash.h >>> index 6981a52b3887..67766e60a6b6 100644 >>> --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h >>> +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h >>> @@ -468,7 +468,7 @@ extern int htab_bolt_mapping(unsigned long vstart, = unsigned long vend, >>> int psize, int ssize); >>> int htab_remove_mapping(unsigned long vstart, unsigned long vend, >>> int psize, int ssize); >>> -extern void add_gpage(u64 addr, u64 page_size, unsigned long number_of= _pages); >>> +extern void pSeries_add_gpage(u64 addr, u64 page_size, unsigned long n= umber_of_pages); >>=20 >> Linux kernel coding style says 'mixed-case names are frowned upon' > > True, but there is precedent within arch/powerpc/platforms/pseries seeing= as "pSeries_" is > already used heavily to prefix function names. True, but it's still horrible. Any new names should just use "pseries". cheers ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2 2/2] powerpc/mm/hugetlb: Add support for reserving gigantic huge pages via kernel command line 2017-06-02 3:03 ` Michael Ellerman @ 2017-06-05 7:47 ` Aneesh Kumar K.V 0 siblings, 0 replies; 8+ messages in thread From: Aneesh Kumar K.V @ 2017-06-05 7:47 UTC (permalink / raw) To: Michael Ellerman, Tyrel Datwyler, christophe leroy, benh, paulus Cc: Scott Wood, linuxppc-dev Michael Ellerman <mpe@ellerman.id.au> writes: > Tyrel Datwyler <tyreld@linux.vnet.ibm.com> writes: >> On 06/01/2017 09:42 AM, christophe leroy wrote: >>> Le 01/06/2017 =C3=A0 16:30, Aneesh Kumar K.V a =C3=A9crit : >>>> diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h b/arch/powe= rpc/include/asm/book3s/64/mmu-hash.h >>>> index 6981a52b3887..67766e60a6b6 100644 >>>> --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h >>>> +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h >>>> @@ -468,7 +468,7 @@ extern int htab_bolt_mapping(unsigned long vstart,= unsigned long vend, >>>> int psize, int ssize); >>>> int htab_remove_mapping(unsigned long vstart, unsigned long vend, >>>> int psize, int ssize); >>>> -extern void add_gpage(u64 addr, u64 page_size, unsigned long number_o= f_pages); >>>> +extern void pSeries_add_gpage(u64 addr, u64 page_size, unsigned long = number_of_pages); >>>=20 >>> Linux kernel coding style says 'mixed-case names are frowned upon' >> >> True, but there is precedent within arch/powerpc/platforms/pseries seein= g as "pSeries_" is >> already used heavily to prefix function names. > > True, but it's still horrible. Any new names should just use "pseries". I will update in the next iteration. I will wait to get feedback on FSL/8xx before posting the next version. -aneesh ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2 2/2] powerpc/mm/hugetlb: Add support for reserving gigantic huge pages via kernel command line 2017-06-01 16:42 ` christophe leroy 2017-06-01 19:11 ` Tyrel Datwyler @ 2017-06-05 7:47 ` Aneesh Kumar K.V 2017-06-09 16:13 ` Christophe LEROY 1 sibling, 1 reply; 8+ messages in thread From: Aneesh Kumar K.V @ 2017-06-05 7:47 UTC (permalink / raw) To: christophe leroy, benh, paulus, mpe; +Cc: linuxppc-dev, Scott Wood christophe leroy <christophe.leroy@c-s.fr> writes: > Le 01/06/2017 =C3=A0 16:30, Aneesh Kumar K.V a =C3=A9crit : >> With commit aa888a74977a8 ("hugetlb: support larger than MAX_ORDER") we = added >> support for allocating gigantic hugepages via kernel command line. Switch >> ppc64 arch specific code to use that. > > Is it only ppc64 ? Your patch removes things defined for the 8xx and=20 > modifies stuff in init_32.c > > On the 8xx, as far as I remember, 8M pages on 4k pages mode are above=20 > default MAX_ORDER, I solved it by increasing MAX_ORDER. Is that wrong ? I was hoping every platform can switch to generic code. Obviously I didn't test the changes on anything other than ppc64. Can you try with this patchset and pass hugepagesz=3D<size> hugepages=3D<number> kernel arg and see if hugepage allocation works for you ? > >> >> W.r.t FSL support, we now limit our allocation range using BOOTMEM_ALLOC= _ACCESSIBLE. >> >> We use the kernel command line to do reservation of hugetlb pages on pow= ernv >> platforms. On pseries hash mmu mode the supported gigantic huge page siz= e is >> 16GB and that can only be allocated with hypervisor assist. For pseries = the >> command line option doesn't do the allocation. Instead pseries does giga= ntic >> hugepage allocation based on hypervisor hint that is specified via >> "ibm,expected#pages" property of the memory node. >> >> Cc: Scott Wood <oss@buserror.net> >> Cc: Christophe Leroy <christophe.leroy@c-s.fr> >> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> >> --- >> arch/powerpc/include/asm/book3s/64/mmu-hash.h | 2 +- >> arch/powerpc/include/asm/hugetlb.h | 14 -- >> arch/powerpc/kernel/setup-common.c | 7 - >> arch/powerpc/mm/hash_utils_64.c | 2 +- >> arch/powerpc/mm/hugetlbpage.c | 177 +++----------------= ------- >> arch/powerpc/mm/init_32.c | 2 - >> 6 files changed, 22 insertions(+), 182 deletions(-) >> >> diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h b/arch/powerp= c/include/asm/book3s/64/mmu-hash.h >> index 6981a52b3887..67766e60a6b6 100644 >> --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h >> +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h >> @@ -468,7 +468,7 @@ extern int htab_bolt_mapping(unsigned long vstart, u= nsigned long vend, >> int psize, int ssize); >> int htab_remove_mapping(unsigned long vstart, unsigned long vend, >> int psize, int ssize); >> -extern void add_gpage(u64 addr, u64 page_size, unsigned long number_of_= pages); >> +extern void pSeries_add_gpage(u64 addr, u64 page_size, unsigned long nu= mber_of_pages); > > Linux kernel coding style says 'mixed-case names are frowned upon' Agreed, but that is how we named all the pseries related functions in platforms/pseries/*.c files. Hence i kept the same naming style. -aneesh ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2 2/2] powerpc/mm/hugetlb: Add support for reserving gigantic huge pages via kernel command line 2017-06-05 7:47 ` Aneesh Kumar K.V @ 2017-06-09 16:13 ` Christophe LEROY 0 siblings, 0 replies; 8+ messages in thread From: Christophe LEROY @ 2017-06-09 16:13 UTC (permalink / raw) To: Aneesh Kumar K.V, benh, paulus, mpe; +Cc: linuxppc-dev, Scott Wood Le 05/06/2017 à 09:47, Aneesh Kumar K.V a écrit : > christophe leroy <christophe.leroy@c-s.fr> writes: > >> Le 01/06/2017 à 16:30, Aneesh Kumar K.V a écrit : >>> With commit aa888a74977a8 ("hugetlb: support larger than MAX_ORDER") we added >>> support for allocating gigantic hugepages via kernel command line. Switch >>> ppc64 arch specific code to use that. >> >> Is it only ppc64 ? Your patch removes things defined for the 8xx and >> modifies stuff in init_32.c >> >> On the 8xx, as far as I remember, 8M pages on 4k pages mode are above >> default MAX_ORDER, I solved it by increasing MAX_ORDER. Is that wrong ? > > > I was hoping every platform can switch to generic code. Obviously I > didn't test the changes on anything other than ppc64. Can you try with > this patchset and pass hugepagesz=<size> hugepages=<number> kernel arg > and see if hugepage allocation works for you ? > I'm sorry I didn't have time to test it this week and I won't have time either in the next two weeks. Christophe ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-06-09 16:13 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-06-01 14:30 [PATCH v2 1/2] mm/hugetlb: Allow arch to override and call the weak function Aneesh Kumar K.V 2017-06-01 14:30 ` [PATCH v2 2/2] powerpc/mm/hugetlb: Add support for reserving gigantic huge pages via kernel command line Aneesh Kumar K.V 2017-06-01 16:42 ` christophe leroy 2017-06-01 19:11 ` Tyrel Datwyler 2017-06-02 3:03 ` Michael Ellerman 2017-06-05 7:47 ` Aneesh Kumar K.V 2017-06-05 7:47 ` Aneesh Kumar K.V 2017-06-09 16:13 ` Christophe LEROY
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.