[RFC PATCH v2 0/2] arm64/hugetlb: enable gigantic page

[RFC PATCH v2 0/2] arm64/hugetlb: enable gigantic page

[Xie Yisheng]

Arm64 supports different size of gigantic page which can be seen from:
commit 084bd29810a5 ("ARM64: mm: HugeTLB support.")
commit 66b3923a1a0f ("arm64: hugetlb: add support for PTE contiguous bit")

So I tried to use this function by adding hugepagesz=1G in kernel
parameters, with CONFIG_CMA=y. However, when I
echo xx > \
  /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
it failed with the following info:
-bash: echo: write error: Invalid argument

This is a v2 patchset which make gigantic page can be used on arm64,
with CONFIG_CMA=y, or other related configs is enable.

You can see the former discussions at:
https://lkml.org/lkml/2016/8/18/310
 
Xie Yisheng (2):
  mm/hugetlb: Introduce ARCH_HAS_GIGANTIC_PAGE
  arm64 Kconfig: Select gigantic page

 arch/arm64/Kconfig | 1 +
 arch/s390/Kconfig  | 1 +
 arch/x86/Kconfig   | 1 +
 fs/Kconfig         | 4 ++++
 mm/hugetlb.c       | 2 +-
 5 files changed, 8 insertions(+), 1 deletion(-)

-- 
1.7.12.4

[RFC PATCH v2 1/2] mm/hugetlb: Introduce ARCH_HAS_GIGANTIC_PAGE

[Xie Yisheng]

Avoid making ifdef get pretty unwieldy if many ARCHs support gigantic page.
No functional change with this patch.

Signed-off-by: Xie Yisheng <xieyisheng1@huawei.com>
---
 arch/s390/Kconfig | 1 +
 arch/x86/Kconfig  | 1 +
 fs/Kconfig        | 4 ++++
 mm/hugetlb.c      | 2 +-
 4 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index e751fe2..a8c8fa3 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -72,6 +72,7 @@ config S390
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_GCOV_PROFILE_ALL
+	select ARCH_HAS_GIGANTIC_PAGE
 	select ARCH_HAS_KCOV
 	select ARCH_HAS_SG_CHAIN
 	select ARCH_HAVE_NMI_SAFE_CMPXCHG
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c580d8c..5cf959c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -29,6 +29,7 @@ config X86
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_FAST_MULTIPLIER
 	select ARCH_HAS_GCOV_PROFILE_ALL
+	select ARCH_HAS_GIGANTIC_PAGE		if X86_64
 	select ARCH_HAS_KCOV			if X86_64
 	select ARCH_HAS_PMEM_API		if X86_64
 	select ARCH_HAS_MMIO_FLUSH
diff --git a/fs/Kconfig b/fs/Kconfig
index 2bc7ad7..b77ad0f 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -199,6 +199,10 @@ config HUGETLBFS
 config HUGETLB_PAGE
 	def_bool HUGETLBFS
 
+config ARCH_HAS_GIGANTIC_PAGE
+	depends on HUGETLB_PAGE
+	bool
+
 source "fs/configfs/Kconfig"
 source "fs/efivarfs/Kconfig"
 
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 87e11d8..8488dcc 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1022,7 +1022,7 @@ static int hstate_next_node_to_free(struct hstate *h, nodemask_t *nodes_allowed)
 		((node = hstate_next_node_to_free(hs, mask)) || 1);	\
 		nr_nodes--)
 
-#if (defined(CONFIG_X86_64) || defined(CONFIG_S390)) && \
+#if defined(CONFIG_ARCH_HAS_GIGANTIC_PAGE) && \
 	((defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) || \
 	defined(CONFIG_CMA))
 static void destroy_compound_gigantic_page(struct page *page,
-- 
1.7.12.4

[RFC PATCH v2 2/2] arm64 Kconfig: Select gigantic page

[Xie Yisheng]

Arm64 supports gigantic page after
commit 084bd29810a5 ("ARM64: mm: HugeTLB support.")
however, it got broken by 
commit 944d9fec8d7a ("hugetlb: add support for gigantic page
allocation at runtime")

This patch selects ARCH_HAS_GIGANTIC_PAGE to make this
function can be used again.

Signed-off-by: Xie Yisheng <xieyisheng1@huawei.com>
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index bc3f00f..92217f6 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -9,6 +9,7 @@ config ARM64
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_GCOV_PROFILE_ALL
+	select ARCH_HAS_GIGANTIC_PAGE
 	select ARCH_HAS_KCOV
 	select ARCH_HAS_SG_CHAIN
 	select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
-- 
1.7.12.4

Re: [RFC PATCH v2 1/2] mm/hugetlb: Introduce ARCH_HAS_GIGANTIC_PAGE

[Michal Hocko]

On Mon 22-08-16 10:56:42, Xie Yisheng wrote:
> Avoid making ifdef get pretty unwieldy if many ARCHs support gigantic page.
> No functional change with this patch.
> 
> Signed-off-by: Xie Yisheng <xieyisheng1@huawei.com>
> ---
>  arch/s390/Kconfig | 1 +
>  arch/x86/Kconfig  | 1 +
>  fs/Kconfig        | 4 ++++
>  mm/hugetlb.c      | 2 +-
>  4 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index e751fe2..a8c8fa3 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -72,6 +72,7 @@ config S390
>  	select ARCH_HAS_DEVMEM_IS_ALLOWED
>  	select ARCH_HAS_ELF_RANDOMIZE
>  	select ARCH_HAS_GCOV_PROFILE_ALL
> +	select ARCH_HAS_GIGANTIC_PAGE
>  	select ARCH_HAS_KCOV
>  	select ARCH_HAS_SG_CHAIN
>  	select ARCH_HAVE_NMI_SAFE_CMPXCHG
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index c580d8c..5cf959c 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -29,6 +29,7 @@ config X86
>  	select ARCH_HAS_ELF_RANDOMIZE
>  	select ARCH_HAS_FAST_MULTIPLIER
>  	select ARCH_HAS_GCOV_PROFILE_ALL
> +	select ARCH_HAS_GIGANTIC_PAGE		if X86_64
>  	select ARCH_HAS_KCOV			if X86_64
>  	select ARCH_HAS_PMEM_API		if X86_64
>  	select ARCH_HAS_MMIO_FLUSH

good

> diff --git a/fs/Kconfig b/fs/Kconfig
> index 2bc7ad7..b77ad0f 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -199,6 +199,10 @@ config HUGETLBFS
>  config HUGETLB_PAGE
>  	def_bool HUGETLBFS
>  
> +config ARCH_HAS_GIGANTIC_PAGE
> +	depends on HUGETLB_PAGE
> +	bool
> +

but is this really necessary? The code where we use
ARCH_HAS_GIGANTIC_PAGE already depends on HUGETLB_PAGE.

Other than that looks good to me and a nice simplification.

>  source "fs/configfs/Kconfig"
>  source "fs/efivarfs/Kconfig"
>  
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 87e11d8..8488dcc 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1022,7 +1022,7 @@ static int hstate_next_node_to_free(struct hstate *h, nodemask_t *nodes_allowed)
>  		((node = hstate_next_node_to_free(hs, mask)) || 1);	\
>  		nr_nodes--)
>  
> -#if (defined(CONFIG_X86_64) || defined(CONFIG_S390)) && \
> +#if defined(CONFIG_ARCH_HAS_GIGANTIC_PAGE) && \
>  	((defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) || \
>  	defined(CONFIG_CMA))
>  static void destroy_compound_gigantic_page(struct page *page,
> -- 
> 1.7.12.4

-- 
Michal Hocko
SUSE Labs

Re: [RFC PATCH v2 2/2] arm64 Kconfig: Select gigantic page

[Michal Hocko]

On Mon 22-08-16 10:56:43, Xie Yisheng wrote:
> Arm64 supports gigantic page after
> commit 084bd29810a5 ("ARM64: mm: HugeTLB support.")
> however, it got broken by 
> commit 944d9fec8d7a ("hugetlb: add support for gigantic page
> allocation at runtime")
> 
> This patch selects ARCH_HAS_GIGANTIC_PAGE to make this
> function can be used again.

I haven't double checked that the above commit really broke it but if
that is the case then
 
Fixes: 944d9fec8d7a ("hugetlb: add support for gigantic page allocation at runtime")

would be nice as well I guess. I do not think that marking it for stable
is really necessary considering how long it's been broken and nobody has
noticed...

> Signed-off-by: Xie Yisheng <xieyisheng1@huawei.com>

Acked-by: Michal Hocko <mhocko@suse.com>

> ---
>  arch/arm64/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index bc3f00f..92217f6 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -9,6 +9,7 @@ config ARM64
>  	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
>  	select ARCH_HAS_ELF_RANDOMIZE
>  	select ARCH_HAS_GCOV_PROFILE_ALL
> +	select ARCH_HAS_GIGANTIC_PAGE
>  	select ARCH_HAS_KCOV
>  	select ARCH_HAS_SG_CHAIN
>  	select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> -- 
> 1.7.12.4
> 

-- 
Michal Hocko
SUSE Labs

Re: [RFC PATCH v2 2/2] arm64 Kconfig: Select gigantic page

[Catalin Marinas]

On Mon, Aug 22, 2016 at 10:03:58AM +0200, Michal Hocko wrote:
> On Mon 22-08-16 10:56:43, Xie Yisheng wrote:
> > Arm64 supports gigantic page after
> > commit 084bd29810a5 ("ARM64: mm: HugeTLB support.")
> > however, it got broken by 
> > commit 944d9fec8d7a ("hugetlb: add support for gigantic page
> > allocation at runtime")
> > 
> > This patch selects ARCH_HAS_GIGANTIC_PAGE to make this
> > function can be used again.
> 
> I haven't double checked that the above commit really broke it but if
> that is the case then
>  
> Fixes: 944d9fec8d7a ("hugetlb: add support for gigantic page allocation at runtime")
> 
> would be nice as well I guess. I do not think that marking it for stable
> is really necessary considering how long it's been broken and nobody has
> noticed...

I'm not sure that commit broke it. The gigantic functionality introduced
by the above commit was under an #ifdef CONFIG_X86_64. Prior
to that we had a VM_BUG_ON(hstate_is_gigantic(h)).

-- 
Catalin

Re: [RFC PATCH v2 2/2] arm64 Kconfig: Select gigantic page

[Catalin Marinas]

On Mon, Aug 22, 2016 at 10:56:43AM +0800, Xie Yisheng wrote:
> Arm64 supports gigantic page after
> commit 084bd29810a5 ("ARM64: mm: HugeTLB support.")
> however, it got broken by 
> commit 944d9fec8d7a ("hugetlb: add support for gigantic page
> allocation at runtime")
> 
> This patch selects ARCH_HAS_GIGANTIC_PAGE to make this
> function can be used again.
> 
> Signed-off-by: Xie Yisheng <xieyisheng1@huawei.com>
> ---
>  arch/arm64/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index bc3f00f..92217f6 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -9,6 +9,7 @@ config ARM64
>  	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
>  	select ARCH_HAS_ELF_RANDOMIZE
>  	select ARCH_HAS_GCOV_PROFILE_ALL
> +	select ARCH_HAS_GIGANTIC_PAGE

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

Re: [RFC PATCH v2 1/2] mm/hugetlb: Introduce ARCH_HAS_GIGANTIC_PAGE

[Yisheng Xie]

On 2016/8/22 16:01, Michal Hocko wrote:
> On Mon 22-08-16 10:56:42, Xie Yisheng wrote:
>>  
>> +config ARCH_HAS_GIGANTIC_PAGE
>> +	depends on HUGETLB_PAGE
>> +	bool
>> +
> 
> but is this really necessary? The code where we use
> ARCH_HAS_GIGANTIC_PAGE already depends on HUGETLB_PAGE.
> 
Hi Michal,
Thank you for your reply.
That right, it's no need to depends on HUGETLB_PAGE here.

I will send v3 soon.

Thanks
Xie Yisheng
> Other than that looks good to me and a nice simplification.
> 
>>  source "fs/configfs/Kconfig"
>>  source "fs/efivarfs/Kconfig"
>>  
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 87e11d8..8488dcc 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -1022,7 +1022,7 @@ static int hstate_next_node_to_free(struct hstate *h, nodemask_t *nodes_allowed)
>>  		((node = hstate_next_node_to_free(hs, mask)) || 1);	\
>>  		nr_nodes--)
>>  
>> -#if (defined(CONFIG_X86_64) || defined(CONFIG_S390)) && \
>> +#if defined(CONFIG_ARCH_HAS_GIGANTIC_PAGE) && \
>>  	((defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) || \
>>  	defined(CONFIG_CMA))
>>  static void destroy_compound_gigantic_page(struct page *page,
>> -- 
>> 1.7.12.4
> 

Re: [RFC PATCH v2 2/2] arm64 Kconfig: Select gigantic page

[Yisheng Xie]

On 2016/8/22 18:00, Catalin Marinas wrote:
> On Mon, Aug 22, 2016 at 10:03:58AM +0200, Michal Hocko wrote:
>> On Mon 22-08-16 10:56:43, Xie Yisheng wrote:
>>> Arm64 supports gigantic page after
>>> commit 084bd29810a5 ("ARM64: mm: HugeTLB support.")
>>> however, it got broken by 
>>> commit 944d9fec8d7a ("hugetlb: add support for gigantic page
>>> allocation at runtime")
>>>
>>> This patch selects ARCH_HAS_GIGANTIC_PAGE to make this
>>> function can be used again.
>>
>> I haven't double checked that the above commit really broke it but if
>> that is the case then
>>  
>> Fixes: 944d9fec8d7a ("hugetlb: add support for gigantic page allocation at runtime")
>>
>> would be nice as well I guess. I do not think that marking it for stable
>> is really necessary considering how long it's been broken and nobody has
>> noticed...
> 
> I'm not sure that commit broke it. The gigantic functionality introduced
> by the above commit was under an #ifdef CONFIG_X86_64. Prior
> to that we had a VM_BUG_ON(hstate_is_gigantic(h)).
> 
Hi Catalin and Michal ,
Thank you for your reply.
Before that commit gigantic pages can only be allocated at boottime and
can't be freed. That why we had VM_BUG_ON(hstate_is_gigantic(h)) in
function update_and_free_page() Prior to that.

Anyway, it should not just add #ifdef CONFIG_X86_64 for arm64 already
supported 1G hugepage before that commit. Right?

Please let me know if I miss something.

Thanks
Xie Yisheng.