powerpc: add hugepagesz boot-time parameter
Subsystems (2)
PATCH v3 1/1 powerpc: add hugepagesz boot-time parameter
Paul, please include this in 2.6.25 if there are no objections.
This patch adds the hugepagesz boot-time parameter for ppc64. It lets one pick the size for huge pages. The choices available are 64K and 16M when the base page size is 4k. It defaults to 16M (previously the only only choice) if nothing or an invalid choice is specified.
Tested 64K huge pages successfully with the libhugetlbfs 1.2.
Changes from v2:
Moved functions from header file into hugetlbpage.c where they are used.
---
Documentation/kernel-parameters.txt +1 -0
@@ -685,6 +685,7 @@ and is between 256 and 4096 characters. It is defined in the file See Documentation/isdn/README.HiSax. hugepages= [HW,X86-32,IA-64] Maximal number of HugeTLB pages. + hugepagesz= [HW,IA-64,PPC] The size of the HugeTLB pages. i8042.direct [HW] Put keyboard port into non-translated mode i8042.dumbkbd [HW] Pretend that controller can only read data from
arch/powerpc/mm/hash_utils_64.c +2 -9
@@ -369,18 +369,11 @@ static void __init htab_init_page_sizes(void)* on what is available */ if (mmu_psize_defs[MMU_PAGE_16M ].shift) - mmu_huge_psize =MMU_PAGE_16M ; +set_huge_psize (MMU_PAGE_16M );/* With 4k/4level pagetables, we can't (for now) cope with a * huge page size < PMD_SIZE */ else if (mmu_psize_defs[MMU_PAGE_1M ].shift) - mmu_huge_psize =MMU_PAGE_1M ; - -/* Calculate HPAGE_SHIFT and sanity check it */ -if (mmu_psize_defs[mmu_huge_psize].shift >MIN_HUGEPTE_SHIFT && - mmu_psize_defs[mmu_huge_psize].shift <SID_SHIFT ) -HPAGE_SHIFT = mmu_psize_defs[mmu_huge_psize].shift; -else -HPAGE_SHIFT =0 ;/* No huge pages dude ! */ +set_huge_psize (MMU_PAGE_1M );#endif /* CONFIG_HUGETLB_PAGE */ }
arch/powerpc/mm/hugetlbpage.c +94 -25
186 lines not on this page · raw message
include/asm-powerpc/mmu-hash64.h +1 -0
@@ -278,6 +278,7 @@ extern int hash_huge_page(struct mm_struct *mm, unsigned long access,extern int htab_bolt_mapping (unsigned long vstart,unsigned long vend,unsigned long pstart,unsigned long mode,int psize,int ssize); +extern void set_huge_psize (int psize);extern void htab_initialize (void );extern void htab_initialize_secondary (void );
Quoted 1 line · Jon Tollefson
Paul, please include this in 2.6.25 if there are no objections.
No objections to this version from me, just questions.
Quoted 4 lines
This patch adds the hugepagesz boot-time parameter for ppc64. =A0It lets one pick the size for huge pages. The choices available are 64K and 16M when the base page size is 4k. It defaults to 16M (previously the only only choice) if nothing or an invalid choice is specified.
We started discussing this in v1, but the discussion got sidetracked:
Is there a technical reason why you don't also allow 1M pages, which may be useful in certain scenarios?
On the Cell/B.E. platforms (IBM/Mercury blades, Toshiba Celleb, PS3), the second large page size is an option that can be set in a HID SPR to either 64KB or 1MB. Unfortunately, we can't do these two simultaneously, but the firmware can change the default and put it into the device tree, or you could have the kernel override the firmware settings.
Going a lot further, do you have plans for a fully dynamic hugepage size, e.g. using a mount option for hugetlbfs? I can see that as rather useful, but at the same time it's probably much more complicated than the boot time option.
Arnd <><
Quoted 4 lines · Arnd Bergmann
We started discussing this in v1, but the discussion got sidetracked:
Is there a technical reason why you don't also allow 1M pages, which may be useful in certain scenarios?
No, it was mostly a matter of the time I have had and machines easily available to me for testing. I don't know of a technical reason that would prevent supporting 1M huge pages, but would want the tests in the libhugetlbfs suite to pass, etc.
Quoted 11 lines
On the Cell/B.E. platforms (IBM/Mercury blades, Toshiba Celleb, PS3), the second large page size is an option that can be set in a HID SPR to either 64KB or 1MB. Unfortunately, we can't do these two simultaneously, but the firmware can change the default and put it into the device tree, or you could have the kernel override the firmware settings.
Going a lot further, do you have plans for a fully dynamic hugepage size, e.g. using a mount option for hugetlbfs? I can see that as rather useful, but at the same time it's probably much more complicated than the boot time option.
Eventually we will want to support dynamic huge page sizes. This is already being looked into. In the meantime we can have some flexibility with a boot-time parameter though.
Quoted 2 lines
Arnd <><
Jon
Quoted 9 lines · Jon Tollefson
Quoted 4 lines · Arnd Bergmann
We started discussing this in v1, but the discussion got sidetracked:
Is there a technical reason why you don't also allow 1M pages, which may be useful in certain scenarios?
=A0=20No, it was mostly a matter of the time I have had and machines easily available to me for testing. =A0I don't know of a technical reason that would prevent supporting 1M huge pages, but would want the tests in the libhugetlbfs suite to pass, etc.
Ok. Do you think the kernel should be able to change the page size settings in that case, or should we rely on whatever the firmware tells us it has configured already?
Arnd <><
On (04/01/08 00:34), Arnd Bergmann didst pronounce:
Quoted 5 lines · Jon Tollefson
Quoted 1 line
Paul, please include this in 2.6.25 if there are no objections.
No objections to this version from me, just questions.
Quoted 9 lines
Quoted 4 lines
This patch adds the hugepagesz boot-time parameter for ppc64. It lets one pick the size for huge pages. The choices available are 64K and 16M when the base page size is 4k. It defaults to 16M (previously the only only choice) if nothing or an invalid choice is specified.
We started discussing this in v1, but the discussion got sidetracked:
Is there a technical reason why you don't also allow 1M pages, which may be useful in certain scenarios?
I cannot see why not although the ideal would be that the necessary information to support the pagesize would be provided by the firmware instead of hard-coded values.
Quoted 8 lines
On the Cell/B.E. platforms (IBM/Mercury blades, Toshiba Celleb, PS3), the second large page size is an option that can be set in a HID SPR to either 64KB or 1MB. Unfortunately, we can't do these two simultaneously, but the firmware can change the default and put it into the device tree, or you could have the kernel override the firmware settings.
Going a lot further, do you have plans for a fully dynamic hugepage size, e.g. using a mount option for hugetlbfs?
A mount option for hugetlbfs to select a hugepage size is a long-term goal. However, a lot of changes are required to support such a thing. Selecting the hugepage size at boot-time is a reasonable starting point and one that might be usable with some additional work by x86-64 on AMD processors supporting 1GiB pages.
Quoted 4 lines
I can see that as rather useful,
but at the same time it's probably much more complicated than the boot time option.
Not probably at all. It is *certainly* much more complicated than the boot-time option :)
Signature · 3 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab
Quoted 15 lines · Mel Gorman
Quoted 5 lines
We started discussing this in v1, but the discussion got sidetracked:
Is there a technical reason why you don't also allow 1M pages, which may be useful in certain scenarios?I cannot see why not although the ideal would be that the necessary information to support the pagesize would be provided by the firmware instead of hard-coded values.
Quoted 5 lines
On the Cell/B.E. platforms (IBM/Mercury blades, Toshiba Celleb, PS3), the second large page size is an option that can be set in a HID SPR to either 64KB or 1MB. Unfortunately, we can't do these two simultaneously, but the firmware can change the default and put it into the device tree, or you could have the kernel override the firmware settings.
The problem with the firmware choosing the page size is that it has much less of an idea about what the user wants to do than the kernel. It's not exclusive however. We can first teach the kernel to deal with firmware setting the 1MB or 1GB page size, and later implement changing the HW setting from the kernel.
Arnd <><