linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] mm/khugepaged: increase transparent_hugepage_recommend_disable parameter to disable active modification of min_free_kbytes
@ 2023-08-17  3:51 Liu Song
  2023-08-25  8:38 ` Liu Song
  2023-08-29 20:04 ` Yang Shi
  0 siblings, 2 replies; 5+ messages in thread
From: Liu Song @ 2023-08-17  3:51 UTC (permalink / raw)
  To: corbet, akpm, paulmck, rdunlap, catalin.marinas, dave.hansen, rostedt
  Cc: linux-doc, linux-kernel, linux-mm, liusong

In the arm64 environment, when PAGESIZE is 4K, the "pageblock_nr_pages"
value is 512, and the recommended min_free_kbytes in
"set_recommended_min_free_kbytes" usually does not exceed 44MB.

However, when PAGESIZE is 64K, the "pageblock_nr_pages" value is 8192,
and the recommended min_free_kbytes in "set_recommended_min_free_kbytes"
is 8192 * 2 * (2 + 9) * 64K, which directly increases to 11GB.

According to this calculation method, due to the modification of min_free_kbytes,
the reserved memory in my 128GB memory environment reaches 10GB, and MemAvailable
is correspondingly reduced by 10GB.

In the case of PAGESIZE 64K, transparent hugepages are 512MB, and we only
need them to be used on demand. If transparent hugepages cannot be allocated,
falling back to regular 64K pages is completely acceptable.

Therefore, we added the transparent_hugepage_recommend_disable parameter
to disable active modification of min_free_kbytes, thereby meeting our
requirements for transparent hugepages in the 64K scenario, and it will
not excessively reduce the available memory.

Signed-off-by: Liu Song <liusong@linux.alibaba.com>
---
 .../admin-guide/kernel-parameters.txt         |  5 +++++
 mm/khugepaged.c                               | 20 ++++++++++++++++++-
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 654d0d921101..612bdf601cce 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -6553,6 +6553,11 @@
 			See Documentation/admin-guide/mm/transhuge.rst
 			for more details.
 
+	transparent_hugepage_recommend_disable
+			[KNL,THP]
+			Can be used to disable transparent hugepage to actively modify
+			/proc/sys/vm/min_free_kbytes during enablement process.
+
 	trusted.source=	[KEYS]
 			Format: <string>
 			This parameter identifies the trust source as a backend
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 78fc1a24a1cc..ac40c618f4f6 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -88,6 +88,9 @@ static unsigned int khugepaged_max_ptes_none __read_mostly;
 static unsigned int khugepaged_max_ptes_swap __read_mostly;
 static unsigned int khugepaged_max_ptes_shared __read_mostly;
 
+/* default enable recommended */
+static unsigned int transparent_hugepage_recommend __read_mostly = 1;
+
 #define MM_SLOTS_HASH_BITS 10
 static DEFINE_READ_MOSTLY_HASHTABLE(mm_slots_hash, MM_SLOTS_HASH_BITS);
 
@@ -2561,6 +2564,11 @@ static void set_recommended_min_free_kbytes(void)
 		goto update_wmarks;
 	}
 
+	if (!transparent_hugepage_recommend) {
+		pr_info("do not allow to recommend modify min_free_kbytes\n");
+		return;
+	}
+
 	for_each_populated_zone(zone) {
 		/*
 		 * We don't need to worry about fragmentation of
@@ -2591,7 +2599,10 @@ static void set_recommended_min_free_kbytes(void)
 
 	if (recommended_min > min_free_kbytes) {
 		if (user_min_free_kbytes >= 0)
-			pr_info("raising min_free_kbytes from %d to %lu to help transparent hugepage allocations\n",
+			pr_info("raising user specified min_free_kbytes from %d to %lu to help transparent hugepage allocations\n",
+				min_free_kbytes, recommended_min);
+		else
+			pr_info("raising default min_free_kbytes from %d to %lu to help transparent hugepage allocations\n",
 				min_free_kbytes, recommended_min);
 
 		min_free_kbytes = recommended_min;
@@ -2601,6 +2612,13 @@ static void set_recommended_min_free_kbytes(void)
 	setup_per_zone_wmarks();
 }
 
+static int __init setup_transparent_hugepage_recommend_disable(char *str)
+{
+	transparent_hugepage_recommend = 0;
+	return 1;
+}
+__setup("transparent_hugepage_recommend_disable", setup_transparent_hugepage_recommend_disable);
+
 int start_stop_khugepaged(void)
 {
 	int err = 0;
-- 
2.19.1.6.gb485710b


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] mm/khugepaged: increase transparent_hugepage_recommend_disable parameter to disable active modification of min_free_kbytes
  2023-08-17  3:51 [PATCH] mm/khugepaged: increase transparent_hugepage_recommend_disable parameter to disable active modification of min_free_kbytes Liu Song
@ 2023-08-25  8:38 ` Liu Song
  2023-08-29 20:04 ` Yang Shi
  1 sibling, 0 replies; 5+ messages in thread
From: Liu Song @ 2023-08-25  8:38 UTC (permalink / raw)
  To: corbet, akpm, paulmck, rdunlap, catalin.marinas, dave.hansen, rostedt
  Cc: linux-doc, linux-kernel, linux-mm

Hi

Any suggestions for this patch? Indeed, too much memory is being 
reserved for the 64K PAGESIZE scenario. Looking forward to everyone's 
suggestions.

Thanks

在 2023/8/17 11:51, Liu Song 写道:
> In the arm64 environment, when PAGESIZE is 4K, the "pageblock_nr_pages"
> value is 512, and the recommended min_free_kbytes in
> "set_recommended_min_free_kbytes" usually does not exceed 44MB.
>
> However, when PAGESIZE is 64K, the "pageblock_nr_pages" value is 8192,
> and the recommended min_free_kbytes in "set_recommended_min_free_kbytes"
> is 8192 * 2 * (2 + 9) * 64K, which directly increases to 11GB.
>
> According to this calculation method, due to the modification of min_free_kbytes,
> the reserved memory in my 128GB memory environment reaches 10GB, and MemAvailable
> is correspondingly reduced by 10GB.
>
> In the case of PAGESIZE 64K, transparent hugepages are 512MB, and we only
> need them to be used on demand. If transparent hugepages cannot be allocated,
> falling back to regular 64K pages is completely acceptable.
>
> Therefore, we added the transparent_hugepage_recommend_disable parameter
> to disable active modification of min_free_kbytes, thereby meeting our
> requirements for transparent hugepages in the 64K scenario, and it will
> not excessively reduce the available memory.
>
> Signed-off-by: Liu Song <liusong@linux.alibaba.com>
> ---
>   .../admin-guide/kernel-parameters.txt         |  5 +++++
>   mm/khugepaged.c                               | 20 ++++++++++++++++++-
>   2 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 654d0d921101..612bdf601cce 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -6553,6 +6553,11 @@
>   			See Documentation/admin-guide/mm/transhuge.rst
>   			for more details.
>   
> +	transparent_hugepage_recommend_disable
> +			[KNL,THP]
> +			Can be used to disable transparent hugepage to actively modify
> +			/proc/sys/vm/min_free_kbytes during enablement process.
> +
>   	trusted.source=	[KEYS]
>   			Format: <string>
>   			This parameter identifies the trust source as a backend
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index 78fc1a24a1cc..ac40c618f4f6 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -88,6 +88,9 @@ static unsigned int khugepaged_max_ptes_none __read_mostly;
>   static unsigned int khugepaged_max_ptes_swap __read_mostly;
>   static unsigned int khugepaged_max_ptes_shared __read_mostly;
>   
> +/* default enable recommended */
> +static unsigned int transparent_hugepage_recommend __read_mostly = 1;
> +
>   #define MM_SLOTS_HASH_BITS 10
>   static DEFINE_READ_MOSTLY_HASHTABLE(mm_slots_hash, MM_SLOTS_HASH_BITS);
>   
> @@ -2561,6 +2564,11 @@ static void set_recommended_min_free_kbytes(void)
>   		goto update_wmarks;
>   	}
>   
> +	if (!transparent_hugepage_recommend) {
> +		pr_info("do not allow to recommend modify min_free_kbytes\n");
> +		return;
> +	}
> +
>   	for_each_populated_zone(zone) {
>   		/*
>   		 * We don't need to worry about fragmentation of
> @@ -2591,7 +2599,10 @@ static void set_recommended_min_free_kbytes(void)
>   
>   	if (recommended_min > min_free_kbytes) {
>   		if (user_min_free_kbytes >= 0)
> -			pr_info("raising min_free_kbytes from %d to %lu to help transparent hugepage allocations\n",
> +			pr_info("raising user specified min_free_kbytes from %d to %lu to help transparent hugepage allocations\n",
> +				min_free_kbytes, recommended_min);
> +		else
> +			pr_info("raising default min_free_kbytes from %d to %lu to help transparent hugepage allocations\n",
>   				min_free_kbytes, recommended_min);
>   
>   		min_free_kbytes = recommended_min;
> @@ -2601,6 +2612,13 @@ static void set_recommended_min_free_kbytes(void)
>   	setup_per_zone_wmarks();
>   }
>   
> +static int __init setup_transparent_hugepage_recommend_disable(char *str)
> +{
> +	transparent_hugepage_recommend = 0;
> +	return 1;
> +}
> +__setup("transparent_hugepage_recommend_disable", setup_transparent_hugepage_recommend_disable);
> +
>   int start_stop_khugepaged(void)
>   {
>   	int err = 0;

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] mm/khugepaged: increase transparent_hugepage_recommend_disable parameter to disable active modification of min_free_kbytes
  2023-08-17  3:51 [PATCH] mm/khugepaged: increase transparent_hugepage_recommend_disable parameter to disable active modification of min_free_kbytes Liu Song
  2023-08-25  8:38 ` Liu Song
@ 2023-08-29 20:04 ` Yang Shi
  2023-08-31 14:30   ` Liu Song
  1 sibling, 1 reply; 5+ messages in thread
From: Yang Shi @ 2023-08-29 20:04 UTC (permalink / raw)
  To: Liu Song
  Cc: corbet, akpm, paulmck, rdunlap, catalin.marinas, dave.hansen,
	rostedt, linux-doc, linux-kernel, linux-mm

On Wed, Aug 16, 2023 at 8:52 PM Liu Song <liusong@linux.alibaba.com> wrote:
>
> In the arm64 environment, when PAGESIZE is 4K, the "pageblock_nr_pages"
> value is 512, and the recommended min_free_kbytes in
> "set_recommended_min_free_kbytes" usually does not exceed 44MB.
>
> However, when PAGESIZE is 64K, the "pageblock_nr_pages" value is 8192,
> and the recommended min_free_kbytes in "set_recommended_min_free_kbytes"
> is 8192 * 2 * (2 + 9) * 64K, which directly increases to 11GB.
>
> According to this calculation method, due to the modification of min_free_kbytes,
> the reserved memory in my 128GB memory environment reaches 10GB, and MemAvailable
> is correspondingly reduced by 10GB.
>
> In the case of PAGESIZE 64K, transparent hugepages are 512MB, and we only
> need them to be used on demand. If transparent hugepages cannot be allocated,
> falling back to regular 64K pages is completely acceptable.
>
> Therefore, we added the transparent_hugepage_recommend_disable parameter
> to disable active modification of min_free_kbytes, thereby meeting our
> requirements for transparent hugepages in the 64K scenario, and it will
> not excessively reduce the available memory.

Thanks for debugging this. I agree 11GB for min_free_kbytes is too
much. But a kernel parameter sounds overkilling to me either. IMHO we
just need to have a better scaling for bigger base page size. For
example, we just keep one or two pageblock for min_free_kbytes when
the base page size is bigger than 4K.

>
> Signed-off-by: Liu Song <liusong@linux.alibaba.com>
> ---
>  .../admin-guide/kernel-parameters.txt         |  5 +++++
>  mm/khugepaged.c                               | 20 ++++++++++++++++++-
>  2 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 654d0d921101..612bdf601cce 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -6553,6 +6553,11 @@
>                         See Documentation/admin-guide/mm/transhuge.rst
>                         for more details.
>
> +       transparent_hugepage_recommend_disable
> +                       [KNL,THP]
> +                       Can be used to disable transparent hugepage to actively modify
> +                       /proc/sys/vm/min_free_kbytes during enablement process.
> +
>         trusted.source= [KEYS]
>                         Format: <string>
>                         This parameter identifies the trust source as a backend
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index 78fc1a24a1cc..ac40c618f4f6 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -88,6 +88,9 @@ static unsigned int khugepaged_max_ptes_none __read_mostly;
>  static unsigned int khugepaged_max_ptes_swap __read_mostly;
>  static unsigned int khugepaged_max_ptes_shared __read_mostly;
>
> +/* default enable recommended */
> +static unsigned int transparent_hugepage_recommend __read_mostly = 1;
> +
>  #define MM_SLOTS_HASH_BITS 10
>  static DEFINE_READ_MOSTLY_HASHTABLE(mm_slots_hash, MM_SLOTS_HASH_BITS);
>
> @@ -2561,6 +2564,11 @@ static void set_recommended_min_free_kbytes(void)
>                 goto update_wmarks;
>         }
>
> +       if (!transparent_hugepage_recommend) {
> +               pr_info("do not allow to recommend modify min_free_kbytes\n");
> +               return;
> +       }
> +
>         for_each_populated_zone(zone) {
>                 /*
>                  * We don't need to worry about fragmentation of
> @@ -2591,7 +2599,10 @@ static void set_recommended_min_free_kbytes(void)
>
>         if (recommended_min > min_free_kbytes) {
>                 if (user_min_free_kbytes >= 0)
> -                       pr_info("raising min_free_kbytes from %d to %lu to help transparent hugepage allocations\n",
> +                       pr_info("raising user specified min_free_kbytes from %d to %lu to help transparent hugepage allocations\n",
> +                               min_free_kbytes, recommended_min);
> +               else
> +                       pr_info("raising default min_free_kbytes from %d to %lu to help transparent hugepage allocations\n",
>                                 min_free_kbytes, recommended_min);
>
>                 min_free_kbytes = recommended_min;
> @@ -2601,6 +2612,13 @@ static void set_recommended_min_free_kbytes(void)
>         setup_per_zone_wmarks();
>  }
>
> +static int __init setup_transparent_hugepage_recommend_disable(char *str)
> +{
> +       transparent_hugepage_recommend = 0;
> +       return 1;
> +}
> +__setup("transparent_hugepage_recommend_disable", setup_transparent_hugepage_recommend_disable);
> +
>  int start_stop_khugepaged(void)
>  {
>         int err = 0;
> --
> 2.19.1.6.gb485710b
>
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] mm/khugepaged: increase transparent_hugepage_recommend_disable parameter to disable active modification of min_free_kbytes
  2023-08-29 20:04 ` Yang Shi
@ 2023-08-31 14:30   ` Liu Song
  2023-09-01 17:29     ` Yang Shi
  0 siblings, 1 reply; 5+ messages in thread
From: Liu Song @ 2023-08-31 14:30 UTC (permalink / raw)
  To: Yang Shi
  Cc: corbet, akpm, paulmck, rdunlap, catalin.marinas, dave.hansen,
	rostedt, linux-doc, linux-kernel, linux-mm

在 2023/8/30 04:04, Yang Shi 写道:

> On Wed, Aug 16, 2023 at 8:52 PM Liu Song <liusong@linux.alibaba.com> wrote:
>> In the arm64 environment, when PAGESIZE is 4K, the "pageblock_nr_pages"
>> value is 512, and the recommended min_free_kbytes in
>> "set_recommended_min_free_kbytes" usually does not exceed 44MB.
>>
>> However, when PAGESIZE is 64K, the "pageblock_nr_pages" value is 8192,
>> and the recommended min_free_kbytes in "set_recommended_min_free_kbytes"
>> is 8192 * 2 * (2 + 9) * 64K, which directly increases to 11GB.
>>
>> According to this calculation method, due to the modification of min_free_kbytes,
>> the reserved memory in my 128GB memory environment reaches 10GB, and MemAvailable
>> is correspondingly reduced by 10GB.
>>
>> In the case of PAGESIZE 64K, transparent hugepages are 512MB, and we only
>> need them to be used on demand. If transparent hugepages cannot be allocated,
>> falling back to regular 64K pages is completely acceptable.
>>
>> Therefore, we added the transparent_hugepage_recommend_disable parameter
>> to disable active modification of min_free_kbytes, thereby meeting our
>> requirements for transparent hugepages in the 64K scenario, and it will
>> not excessively reduce the available memory.
> Thanks for debugging this. I agree 11GB for min_free_kbytes is too
> much. But a kernel parameter sounds overkilling to me either. IMHO we
> just need to have a better scaling for bigger base page size. For
> example, we just keep one or two pageblock for min_free_kbytes when
> the base page size is bigger than 4K.
>
Thank you very much for your advice, but how do we determine the number 
of pageblocks?
This is a difficult number to determine. When PAGESIZE is 64K, arm64 
supports hugepages
of 2M, 512M, and 16G, which can meet the requirements of scenarios that 
require hugepages.

However, transparent huge pages can only support 512M, and 512M is a 
very large number, so
enabling transparent huge pages should be carefully considered, not to 
mention whether it makes
sense to reserve such a large amount of memory.

Therefore, I think that in the scenario of 64K PAGESIZE, it might also 
be a good choice to directly
cancel set_recommended_min_free_kbytes?

Thanks


>> Signed-off-by: Liu Song <liusong@linux.alibaba.com>
>> ---
>>   .../admin-guide/kernel-parameters.txt         |  5 +++++
>>   mm/khugepaged.c                               | 20 ++++++++++++++++++-
>>   2 files changed, 24 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 654d0d921101..612bdf601cce 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -6553,6 +6553,11 @@
>>                          See Documentation/admin-guide/mm/transhuge.rst
>>                          for more details.
>>
>> +       transparent_hugepage_recommend_disable
>> +                       [KNL,THP]
>> +                       Can be used to disable transparent hugepage to actively modify
>> +                       /proc/sys/vm/min_free_kbytes during enablement process.
>> +
>>          trusted.source= [KEYS]
>>                          Format: <string>
>>                          This parameter identifies the trust source as a backend
>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>> index 78fc1a24a1cc..ac40c618f4f6 100644
>> --- a/mm/khugepaged.c
>> +++ b/mm/khugepaged.c
>> @@ -88,6 +88,9 @@ static unsigned int khugepaged_max_ptes_none __read_mostly;
>>   static unsigned int khugepaged_max_ptes_swap __read_mostly;
>>   static unsigned int khugepaged_max_ptes_shared __read_mostly;
>>
>> +/* default enable recommended */
>> +static unsigned int transparent_hugepage_recommend __read_mostly = 1;
>> +
>>   #define MM_SLOTS_HASH_BITS 10
>>   static DEFINE_READ_MOSTLY_HASHTABLE(mm_slots_hash, MM_SLOTS_HASH_BITS);
>>
>> @@ -2561,6 +2564,11 @@ static void set_recommended_min_free_kbytes(void)
>>                  goto update_wmarks;
>>          }
>>
>> +       if (!transparent_hugepage_recommend) {
>> +               pr_info("do not allow to recommend modify min_free_kbytes\n");
>> +               return;
>> +       }
>> +
>>          for_each_populated_zone(zone) {
>>                  /*
>>                   * We don't need to worry about fragmentation of
>> @@ -2591,7 +2599,10 @@ static void set_recommended_min_free_kbytes(void)
>>
>>          if (recommended_min > min_free_kbytes) {
>>                  if (user_min_free_kbytes >= 0)
>> -                       pr_info("raising min_free_kbytes from %d to %lu to help transparent hugepage allocations\n",
>> +                       pr_info("raising user specified min_free_kbytes from %d to %lu to help transparent hugepage allocations\n",
>> +                               min_free_kbytes, recommended_min);
>> +               else
>> +                       pr_info("raising default min_free_kbytes from %d to %lu to help transparent hugepage allocations\n",
>>                                  min_free_kbytes, recommended_min);
>>
>>                  min_free_kbytes = recommended_min;
>> @@ -2601,6 +2612,13 @@ static void set_recommended_min_free_kbytes(void)
>>          setup_per_zone_wmarks();
>>   }
>>
>> +static int __init setup_transparent_hugepage_recommend_disable(char *str)
>> +{
>> +       transparent_hugepage_recommend = 0;
>> +       return 1;
>> +}
>> +__setup("transparent_hugepage_recommend_disable", setup_transparent_hugepage_recommend_disable);
>> +
>>   int start_stop_khugepaged(void)
>>   {
>>          int err = 0;
>> --
>> 2.19.1.6.gb485710b
>>
>>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] mm/khugepaged: increase transparent_hugepage_recommend_disable parameter to disable active modification of min_free_kbytes
  2023-08-31 14:30   ` Liu Song
@ 2023-09-01 17:29     ` Yang Shi
  0 siblings, 0 replies; 5+ messages in thread
From: Yang Shi @ 2023-09-01 17:29 UTC (permalink / raw)
  To: Liu Song
  Cc: corbet, akpm, paulmck, rdunlap, catalin.marinas, dave.hansen,
	rostedt, linux-doc, linux-kernel, linux-mm

On Thu, Aug 31, 2023 at 7:30 AM Liu Song <liusong@linux.alibaba.com> wrote:
>
> 在 2023/8/30 04:04, Yang Shi 写道:
>
> > On Wed, Aug 16, 2023 at 8:52 PM Liu Song <liusong@linux.alibaba.com> wrote:
> >> In the arm64 environment, when PAGESIZE is 4K, the "pageblock_nr_pages"
> >> value is 512, and the recommended min_free_kbytes in
> >> "set_recommended_min_free_kbytes" usually does not exceed 44MB.
> >>
> >> However, when PAGESIZE is 64K, the "pageblock_nr_pages" value is 8192,
> >> and the recommended min_free_kbytes in "set_recommended_min_free_kbytes"
> >> is 8192 * 2 * (2 + 9) * 64K, which directly increases to 11GB.
> >>
> >> According to this calculation method, due to the modification of min_free_kbytes,
> >> the reserved memory in my 128GB memory environment reaches 10GB, and MemAvailable
> >> is correspondingly reduced by 10GB.
> >>
> >> In the case of PAGESIZE 64K, transparent hugepages are 512MB, and we only
> >> need them to be used on demand. If transparent hugepages cannot be allocated,
> >> falling back to regular 64K pages is completely acceptable.
> >>
> >> Therefore, we added the transparent_hugepage_recommend_disable parameter
> >> to disable active modification of min_free_kbytes, thereby meeting our
> >> requirements for transparent hugepages in the 64K scenario, and it will
> >> not excessively reduce the available memory.
> > Thanks for debugging this. I agree 11GB for min_free_kbytes is too
> > much. But a kernel parameter sounds overkilling to me either. IMHO we
> > just need to have a better scaling for bigger base page size. For
> > example, we just keep one or two pageblock for min_free_kbytes when
> > the base page size is bigger than 4K.
> >
> Thank you very much for your advice, but how do we determine the number
> of pageblocks?

TBH, I can't tell. I don't have a magic number...

> This is a difficult number to determine. When PAGESIZE is 64K, arm64
> supports hugepages
> of 2M, 512M, and 16G, which can meet the requirements of scenarios that
> require hugepages.
>
> However, transparent huge pages can only support 512M, and 512M is a
> very large number, so
> enabling transparent huge pages should be carefully considered, not to
> mention whether it makes
> sense to reserve such a large amount of memory.
>
> Therefore, I think that in the scenario of 64K PAGESIZE, it might also
> be a good choice to directly
> cancel set_recommended_min_free_kbytes?

It should be ok too. There shouldn't be too many real life workloads
running with this configuration other than some Java users may run
some workloads with 64K base page + THP AFAIK. But it should be not
very common.

>
> Thanks
>
>
> >> Signed-off-by: Liu Song <liusong@linux.alibaba.com>
> >> ---
> >>   .../admin-guide/kernel-parameters.txt         |  5 +++++
> >>   mm/khugepaged.c                               | 20 ++++++++++++++++++-
> >>   2 files changed, 24 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> >> index 654d0d921101..612bdf601cce 100644
> >> --- a/Documentation/admin-guide/kernel-parameters.txt
> >> +++ b/Documentation/admin-guide/kernel-parameters.txt
> >> @@ -6553,6 +6553,11 @@
> >>                          See Documentation/admin-guide/mm/transhuge.rst
> >>                          for more details.
> >>
> >> +       transparent_hugepage_recommend_disable
> >> +                       [KNL,THP]
> >> +                       Can be used to disable transparent hugepage to actively modify
> >> +                       /proc/sys/vm/min_free_kbytes during enablement process.
> >> +
> >>          trusted.source= [KEYS]
> >>                          Format: <string>
> >>                          This parameter identifies the trust source as a backend
> >> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> >> index 78fc1a24a1cc..ac40c618f4f6 100644
> >> --- a/mm/khugepaged.c
> >> +++ b/mm/khugepaged.c
> >> @@ -88,6 +88,9 @@ static unsigned int khugepaged_max_ptes_none __read_mostly;
> >>   static unsigned int khugepaged_max_ptes_swap __read_mostly;
> >>   static unsigned int khugepaged_max_ptes_shared __read_mostly;
> >>
> >> +/* default enable recommended */
> >> +static unsigned int transparent_hugepage_recommend __read_mostly = 1;
> >> +
> >>   #define MM_SLOTS_HASH_BITS 10
> >>   static DEFINE_READ_MOSTLY_HASHTABLE(mm_slots_hash, MM_SLOTS_HASH_BITS);
> >>
> >> @@ -2561,6 +2564,11 @@ static void set_recommended_min_free_kbytes(void)
> >>                  goto update_wmarks;
> >>          }
> >>
> >> +       if (!transparent_hugepage_recommend) {
> >> +               pr_info("do not allow to recommend modify min_free_kbytes\n");
> >> +               return;
> >> +       }
> >> +
> >>          for_each_populated_zone(zone) {
> >>                  /*
> >>                   * We don't need to worry about fragmentation of
> >> @@ -2591,7 +2599,10 @@ static void set_recommended_min_free_kbytes(void)
> >>
> >>          if (recommended_min > min_free_kbytes) {
> >>                  if (user_min_free_kbytes >= 0)
> >> -                       pr_info("raising min_free_kbytes from %d to %lu to help transparent hugepage allocations\n",
> >> +                       pr_info("raising user specified min_free_kbytes from %d to %lu to help transparent hugepage allocations\n",
> >> +                               min_free_kbytes, recommended_min);
> >> +               else
> >> +                       pr_info("raising default min_free_kbytes from %d to %lu to help transparent hugepage allocations\n",
> >>                                  min_free_kbytes, recommended_min);
> >>
> >>                  min_free_kbytes = recommended_min;
> >> @@ -2601,6 +2612,13 @@ static void set_recommended_min_free_kbytes(void)
> >>          setup_per_zone_wmarks();
> >>   }
> >>
> >> +static int __init setup_transparent_hugepage_recommend_disable(char *str)
> >> +{
> >> +       transparent_hugepage_recommend = 0;
> >> +       return 1;
> >> +}
> >> +__setup("transparent_hugepage_recommend_disable", setup_transparent_hugepage_recommend_disable);
> >> +
> >>   int start_stop_khugepaged(void)
> >>   {
> >>          int err = 0;
> >> --
> >> 2.19.1.6.gb485710b
> >>
> >>

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-09-01 17:29 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-17  3:51 [PATCH] mm/khugepaged: increase transparent_hugepage_recommend_disable parameter to disable active modification of min_free_kbytes Liu Song
2023-08-25  8:38 ` Liu Song
2023-08-29 20:04 ` Yang Shi
2023-08-31 14:30   ` Liu Song
2023-09-01 17:29     ` Yang Shi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).