linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Liu Song <liusong@linux.alibaba.com>
To: corbet@lwn.net, akpm@linux-foundation.org, paulmck@kernel.org,
	rdunlap@infradead.org, catalin.marinas@arm.com,
	dave.hansen@linux.intel.com, rostedt@goodmis.org
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH] mm/khugepaged: increase transparent_hugepage_recommend_disable parameter to disable active modification of min_free_kbytes
Date: Fri, 25 Aug 2023 16:38:19 +0800	[thread overview]
Message-ID: <cc5a3029-3698-1310-519a-c545f7e515b7@linux.alibaba.com> (raw)
In-Reply-To: <20230817035155.84230-1-liusong@linux.alibaba.com>

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;


  reply	other threads:[~2023-08-25  8:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-17  3:51 Liu Song
2023-08-25  8:38 ` Liu Song [this message]
2023-08-29 20:04 ` Yang Shi
2023-08-31 14:30   ` Liu Song
2023-09-01 17:29     ` Yang Shi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cc5a3029-3698-1310-519a-c545f7e515b7@linux.alibaba.com \
    --to=liusong@linux.alibaba.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=paulmck@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox