Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1467317 > unrolled thread

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

Started byXie Yisheng <xieyisheng1@huawei.com>
First post2016-08-22 05:00 +0200
Last post2016-08-22 13:00 +0200
Articles 3 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [RFC PATCH v2 1/2] mm/hugetlb: Introduce ARCH_HAS_GIGANTIC_PAGE Xie Yisheng <xieyisheng1@huawei.com> - 2016-08-22 05:00 +0200
    Re: [RFC PATCH v2 1/2] mm/hugetlb: Introduce ARCH_HAS_GIGANTIC_PAGE Michal Hocko <mhocko@kernel.org> - 2016-08-22 10:10 +0200
      Re: [RFC PATCH v2 1/2] mm/hugetlb: Introduce ARCH_HAS_GIGANTIC_PAGE Yisheng Xie <xieyisheng1@huawei.com> - 2016-08-22 13:00 +0200

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

FromXie Yisheng <xieyisheng1@huawei.com>
Date2016-08-22 05:00 +0200
Subject[RFC PATCH v2 1/2] mm/hugetlb: Introduce ARCH_HAS_GIGANTIC_PAGE
Message-ID<s8NCV-mn-13@gated-at.bofh.it>
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

[toc] | [next] | [standalone]


#1467441

FromMichal Hocko <mhocko@kernel.org>
Date2016-08-22 10:10 +0200
Message-ID<s8SsV-3Ku-37@gated-at.bofh.it>
In reply to#1467317
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

[toc] | [prev] | [next] | [standalone]


#1467550

FromYisheng Xie <xieyisheng1@huawei.com>
Date2016-08-22 13:00 +0200
Message-ID<s8V7r-5dF-13@gated-at.bofh.it>
In reply to#1467441

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
> 

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web