Currently both the ARCH_WANT_GENERAL_HUGETLB functions 'huge_pte_alloc'
and 'huge_pte_offset' dont take into account huge page implementation
at the PGD level. With addition of PGD awareness into these functions,
more architectures like POWER which also implements huge pages at PGD
level (along with PMD level), can use ARCH_WANT_GENERAL_HUGETLB option.
Signed-off-by: Anshuman Khandual <redacted>
---
mm/hugetlb.c | 9 +++++++++
1 file changed, 9 insertions(+)
This just adds 'follow_huge_pgd' function which is will be used
later in this series to make 'follow_page_mask' function aware
of PGD based huge page implementation.
Signed-off-by: Anshuman Khandual <redacted>
---
include/linux/hugetlb.h | 3 +++
mm/hugetlb.c | 10 ++++++++++
2 files changed, 13 insertions(+)
Currently the function 'follow_page_mask' does not take into account
PGD based huge page implementation. This change achieves that and
makes it complete.
Signed-off-by: Anshuman Khandual <redacted>
---
mm/gup.c | 6 ++++++
1 file changed, 6 insertions(+)
Currently the 'huge_pte_offset' function has only one version for
all the configuations and platforms. This change splits the function
into two versions, one for 64K page size based BOOK3S implementation
and the other one for everything else. This change is also one of the
prerequisites towards enabling GENERAL_HUGETLB implementation for
BOOK3S 64K based huge pages.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/powerpc/mm/hugetlbpage.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
From: root <redacted>
Currently the 'huge_pte_alloc' function has two versions, one for the
BOOK3S and the other one for the BOOK3E platforms. This change splits
the BOOK3S version into two parts, one for the 4K page size based
implementation and the other one for the 64K page sized implementation.
This change is one of the prerequisites towards enabling GENERAL_HUGETLB
implementation for BOOK3S 64K based huge pages.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/powerpc/mm/hugetlbpage.c | 67 +++++++++++++++++++++++++++----------------
1 file changed, 43 insertions(+), 24 deletions(-)
With this change, BOOK3S 64K platforms will not use 'follow_huge_addr'
function any more and always return ERR_PTR(-ENIVAL), hence skipping
the BUG_ON(flags & FOLL_GET) test in 'follow_page_mask' function. These
platforms will then fall back on generic follow_huge_* functions for
everything else. While being here, also added 'follow_huge_pgd' function
which was missing earlier.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/powerpc/mm/hugetlbpage.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
This adds two tests for memory page migration. One for normal page
migration which works for both 4K or 64K base page size kernel and
the other one is for huge page migration which works only on 64K
base page sized 16MB huge page implemention at the PMD level.
Signed-off-by: Anshuman Khandual <redacted>
---
tools/testing/selftests/powerpc/mm/Makefile | 14 +-
.../selftests/powerpc/mm/hugepage-migration.c | 30 +++
tools/testing/selftests/powerpc/mm/migration.h | 204 +++++++++++++++++++++
.../testing/selftests/powerpc/mm/page-migration.c | 33 ++++
tools/testing/selftests/powerpc/mm/run_mmtests | 104 +++++++++++
5 files changed, 380 insertions(+), 5 deletions(-)
create mode 100644 tools/testing/selftests/powerpc/mm/hugepage-migration.c
create mode 100644 tools/testing/selftests/powerpc/mm/migration.h
create mode 100644 tools/testing/selftests/powerpc/mm/page-migration.c
create mode 100755 tools/testing/selftests/powerpc/mm/run_mmtests
@@ -0,0 +1,30 @@+/*+*Copyright(C)2015,AnshumanKhandual,IBMCorporation.+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodifyit+*underthetermsoftheGNUGeneralPublicLicenseversion2aspublished+*bytheFreeSoftwareFoundation.+*/+#include"migration.h"++staticinthugepage_migration(void)+{+intret=0;++if((unsignedlong)getpagesize()==0x1000)+printf("Running on base page size 4K\n");++if((unsignedlong)getpagesize()==0x10000)+printf("Running on base page size 64K\n");++ret=test_huge_migration(16*MEM_MB);+ret=test_huge_migration(256*MEM_MB);+ret=test_huge_migration(512*MEM_MB);++returnret;+}++intmain(void)+{+returntest_harness(hugepage_migration,"hugepage_migration");+}
@@ -0,0 +1,33 @@+/*+*Copyright(C)2015,AnshumanKhandual,IBMCorporation.+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodifyit+*underthetermsoftheGNUGeneralPublicLicenseversion2aspublished+*bytheFreeSoftwareFoundation.+*/+#include"migration.h"++staticintpage_migration(void)+{+intret=0;++if((unsignedlong)getpagesize()==0x1000)+printf("Running on base page size 4K\n");++if((unsignedlong)getpagesize()==0x10000)+printf("Running on base page size 64K\n");++ret=test_migration(4*MEM_MB);+ret=test_migration(64*MEM_MB);+ret=test_migration(256*MEM_MB);+ret=test_migration(512*MEM_MB);+ret=test_migration(1*MEM_GB);+ret=test_migration(2*MEM_GB);++returnret;+}++intmain(void)+{+returntest_harness(page_migration,"page_migration");+}
This change enables HugeTLB page migration for PPC64_BOOK3S systems
for HugeTLB pages implemented at the PMD level. It enables the kernel
configuration option ARCH_ENABLE_HUGEPAGE_MIGRATION which turns on
'hugepage_migration_supported' function which is checked for feature
presence during migration.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/powerpc/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
This enables ARCH_WANT_GENERAL_HUGETLB for BOOK3S 64K in Kconfig.
It also implements a new function 'pte_huge' which is required by
function 'huge_pte_alloc' from generic VM. Existing BOOK3S 64K
specific functions 'huge_pte_alloc' and 'huge_pte_offset' (which
are no longer required) are removed with this change.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/powerpc/Kconfig | 4 ++
arch/powerpc/include/asm/book3s/64/hash-64k.h | 8 ++++
arch/powerpc/mm/hugetlbpage.c | 60 ---------------------------
3 files changed, 12 insertions(+), 60 deletions(-)
[ text/plain ]
From: root <redacted>
Currently the 'huge_pte_alloc' function has two versions, one for the
BOOK3S and the other one for the BOOK3E platforms. This change splits
the BOOK3S version into two parts, one for the 4K page size based
implementation and the other one for the 64K page sized implementation.
This change is one of the prerequisites towards enabling GENERAL_HUGETLB
implementation for BOOK3S 64K based huge pages.
I really wish we reduce #ifdefs in C code and start splitting hash
and nonhash code out where ever we can.
What we really want here is a book3s version and in book3s version use
powerpc specific huge_pte_alloc only if GENERAL_HUGETLB was not defined.
Don't limit it to 64k linux page size. We should select between powerpc
specific implementation and generic code using GENERAL_HUGETLB define.
[ text/plain ]
This enables ARCH_WANT_GENERAL_HUGETLB for BOOK3S 64K in Kconfig.
It also implements a new function 'pte_huge' which is required by
function 'huge_pte_alloc' from generic VM. Existing BOOK3S 64K
specific functions 'huge_pte_alloc' and 'huge_pte_offset' (which
are no longer required) are removed with this change.
You want this to be the last patch isn't it ? And you are mixing too
many things in this patch. Why not do this
* book3s specific hash pte routines
* book3s add conditional based on GENERAL_HUGETLB
* Enable GENERAL_HUGETLB for 64k page size config
[ text/plain ]
This adds two tests for memory page migration. One for normal page
migration which works for both 4K or 64K base page size kernel and
the other one is for huge page migration which works only on 64K
base page sized 16MB huge page implemention at the PMD level.
can you also add the test in this commit
e66f17ff717 ("mm/hugetlb: take page table lock in follow_huge_pmd()")
From: Dave Hansen <hidden> Date: 2016-03-09 22:57:36
On 03/09/2016 04:10 AM, Anshuman Khandual wrote:
Currently the 'huge_pte_offset' function has only one version for
all the configuations and platforms. This change splits the function
into two versions, one for 64K page size based BOOK3S implementation
and the other one for everything else. This change is also one of the
prerequisites towards enabling GENERAL_HUGETLB implementation for
BOOK3S 64K based huge pages.
I think there's a bit of background missing here for random folks on
linux-mm to make sense of these patches.
What is BOOK3S and what does it mean for these patches? Why is its 64K
page size implementation different than all the others? Is there a 4K
page size BOOK3S?
Currently the 'huge_pte_offset' function has only one version for
all the configuations and platforms. This change splits the function
into two versions, one for 64K page size based BOOK3S implementation
and the other one for everything else. This change is also one of the
prerequisites towards enabling GENERAL_HUGETLB implementation for
BOOK3S 64K based huge pages.
I think there's a bit of background missing here for random folks on
linux-mm to make sense of these patches.
What is BOOK3S and what does it mean for these patches? Why is its 64K
BOOK3S is the server type in powerpc family of processors which can support
multiple base page sizes like 64K and 4K.
page size implementation different than all the others? Is there a 4K
page size BOOK3S?
It supports huge pages of size 16M as well as 16G and their implementations
are different with respect to base page sizes of 64K and 4K.
Patches 1, 2 and 3 are generic VM changes and the rest are powerpc specific
changes. Should I have split them accordingly and send out differently for
generic and powerpc specific reviews ?
[ text/plain ]
This adds two tests for memory page migration. One for normal page
migration which works for both 4K or 64K base page size kernel and
the other one is for huge page migration which works only on 64K
base page sized 16MB huge page implemention at the PMD level.
can you also add the test in this commit
e66f17ff717 ("mm/hugetlb: take page table lock in follow_huge_pmd()")
Thought about it but thats kind of bit tricky. All self tests have finite
runtime. Test case in that commit has two processes which execute for ever
and try to create the race condition. We can try to run it for *some time*
looking for races instead ?
[ text/plain ]
This enables ARCH_WANT_GENERAL_HUGETLB for BOOK3S 64K in Kconfig.
It also implements a new function 'pte_huge' which is required by
function 'huge_pte_alloc' from generic VM. Existing BOOK3S 64K
specific functions 'huge_pte_alloc' and 'huge_pte_offset' (which
are no longer required) are removed with this change.
You want this to be the last patch isn't it ? And you are mixing too
Yeah, it should be the last one.
many things in this patch. Why not do this
* book3s specific hash pte routines
* book3s add conditional based on GENERAL_HUGETLB
* Enable GENERAL_HUGETLB for 64k page size config
[ text/plain ]
From: root <redacted>
Currently the 'huge_pte_alloc' function has two versions, one for the
BOOK3S and the other one for the BOOK3E platforms. This change splits
the BOOK3S version into two parts, one for the 4K page size based
implementation and the other one for the 64K page sized implementation.
This change is one of the prerequisites towards enabling GENERAL_HUGETLB
implementation for BOOK3S 64K based huge pages.
I really wish we reduce #ifdefs in C code and start splitting hash
and nonhash code out where ever we can.
Okay but here we are only dealing with 64K and 4K configs inside book3s.
I guess it covers both hash and no hash implementations. Not sure if I
got it correctly.
What we really want here is a book3s version and in book3s version use
powerpc specific huge_pte_alloc only if GENERAL_HUGETLB was not defined.
got it.
Don't limit it to 64k linux page size. We should select between powerpc
specific implementation and generic code using GENERAL_HUGETLB define.
Currently both the ARCH_WANT_GENERAL_HUGETLB functions 'huge_pte_alloc'
and 'huge_pte_offset' dont take into account huge page implementation
at the PGD level. With addition of PGD awareness into these functions,
more architectures like POWER which also implements huge pages at PGD
level (along with PMD level), can use ARCH_WANT_GENERAL_HUGETLB option.
Hugh/Mel/Naoya/Andrew,
Thoughts/inputs/suggestions ? Does this change looks okay ?
Currently the function 'follow_page_mask' does not take into account
PGD based huge page implementation. This change achieves that and
makes it complete.
Hugh/Mel/Naoya/Andrew,
Thoughts/inputs/suggestions ? Does this change look okay ?
This just adds 'follow_huge_pgd' function which is will be used
later in this series to make 'follow_page_mask' function aware
of PGD based huge page implementation.
Hugh/Mel/Naoya/Andrew,
Thoughts/inputs/suggestions ? Does this change looks okay ?
From: Andrew Morton <akpm@linux-foundation.org> Date: 2016-03-14 20:29:27
On Fri, 11 Mar 2016 08:31:55 +0530 Anshuman Khandual [off-list ref] wrote:
On 03/09/2016 05:40 PM, Anshuman Khandual wrote:
quoted
Currently both the ARCH_WANT_GENERAL_HUGETLB functions 'huge_pte_alloc'
and 'huge_pte_offset' dont take into account huge page implementation
at the PGD level. With addition of PGD awareness into these functions,
more architectures like POWER which also implements huge pages at PGD
level (along with PMD level), can use ARCH_WANT_GENERAL_HUGETLB option.
Hugh/Mel/Naoya/Andrew,
Thoughts/inputs/suggestions ? Does this change looks okay ?
Patches 1, 2 and 3 look OK to me. Please include them in the powerpc
merge when the patchset is considered ready.
This enables ARCH_WANT_GENERAL_HUGETLB for BOOK3S 64K in Kconfig.
It also implements a new function 'pte_huge' which is required by
function 'huge_pte_alloc' from generic VM. Existing BOOK3S 64K
specific functions 'huge_pte_alloc' and 'huge_pte_offset' (which
are no longer required) are removed with this change.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/powerpc/Kconfig | 4 ++
arch/powerpc/include/asm/book3s/64/hash-64k.h | 8 ++++
arch/powerpc/mm/hugetlbpage.c | 60 ---------------------------
3 files changed, 12 insertions(+), 60 deletions(-)
On the source code, the PowerPC specified huge_pte_alloc() function will not be defined if the configure logic is "!PPC_4K_PAGES && PPC_BOOK3S_64", but on the Kconfig file the general huge_pte_alloc() function will only be defined if the logic is "PPC_64K_PAGES && PPC_BOOK3S_64".
It works if PPC_4K_PAGES and PPC_64K_PAGES always against each other, but I also find PPC_16K_PAGES and PPC_256K_PAGES on the same Kconfig file. What happens if we configure PPC_16K_PAGES instead of PPC_4K_PAGES?
quoted hunk
config NR_IRQS
int "Number of virtual interrupt numbers"
range 32 32768