From: Andrew Morton <akpm@linux-foundation.org>
To: Nimrod Oren <noren@nvidia.com>
Cc: David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>, Zi Yan <ziy@nvidia.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
"Liam R. Howlett" <liam@infradead.org>,
Nico Pache <nico.pache@linux.dev>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>, Lance Yang <lance.yang@linux.dev>,
Usama Arif <usama.arif@linux.dev>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>, Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH] mm/khugepaged: cap min_free_kbytes recommendation at 1 GiB
Date: Tue, 28 Jul 2026 17:17:10 -0700 [thread overview]
Message-ID: <20260728171710.a968591ceea5782270dffcee@linux-foundation.org> (raw)
In-Reply-To: <20260728202014.2517142-1-noren@nvidia.com>
On Tue, 28 Jul 2026 23:20:14 +0300 Nimrod Oren <noren@nvidia.com> wrote:
> When THP is enabled, set_recommended_min_free_kbytes() may raise
> min_free_kbytes using a heuristic that scales with pageblock_nr_pages.
> With MIGRATE_PCPTYPES equal to 3, the formula accounts for 11
> pageblocks for every eligible populated zone before capping the result
> at 5% of low memory.
>
> This is reasonable when a pageblock is 2 MiB, as on common 4 KiB page
> configurations, but scales poorly with larger base page sizes. With
> the default arm64 pageblock sizes, the contribution per eligible zone
> before the 5% cap is:
>
> 4 KiB pages: 2 MiB pageblock, 22 MiB per zone
> 16 KiB pages: 32 MiB pageblock, 352 MiB per zone
> 64 KiB pages: 512 MiB pageblock, 5.5 GiB per zone
>
> Consequently, min_free_kbytes can reach excessive and unwanted levels.
>
> Add an absolute 1 GiB cap to the recommendation, in addition to the
> existing percentage cap. This bounds the automatic recommendation to a
> sane value on systems with large pageblocks while preserving existing
> behavior for typical systems with 2 MiB pageblocks.
Another hard-coded number isn't pretty :(
> mm/khugepaged.c | 7 ++++++-
Now, why is a page-allocator function sitting in khugepaged.c?
Perhaps to avoid a #ifdef CONFIG_TRANSPARENT_HUGEPAGE.
Or perhaps so that page-allocator maintainers don't get cc'ed on
page-allocator patches ;)
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index 27e8f3077e80..d9caf10e05b5 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -23,6 +23,7 @@
> #include <linux/ksm.h>
> #include <linux/pgalloc.h>
> #include <linux/backing-dev.h>
> +#include <linux/sizes.h>
Why this?
> #include <asm/tlb.h>
> #include "internal.h"
> @@ -3096,9 +3097,13 @@ void set_recommended_min_free_kbytes(void)
> recommended_min += pageblock_nr_pages * nr_zones *
> MIGRATE_PCPTYPES * MIGRATE_PCPTYPES;
>
> - /* don't ever allow to reserve more than 5% of the lowmem */
> + /*
> + * Don't ever allow to reserve more than 5% of lowmem or 1 GiB,
> + * whichever is smaller.
> + */
> recommended_min = min(recommended_min,
> (unsigned long) nr_free_buffer_pages() / 20);
> + recommended_min = min(recommended_min, SZ_1G / PAGE_SIZE);
> recommended_min <<= (PAGE_SHIFT-10);
>
> if (recommended_min > min_free_kbytes) {
Is a min_free_kbytes documentation update needed?
Documentation/admin-guide/sysctl/vm.rst.
prev parent reply other threads:[~2026-07-29 0:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 20:20 [PATCH] mm/khugepaged: cap min_free_kbytes recommendation at 1 GiB Nimrod Oren
2026-07-29 0:17 ` Andrew Morton [this message]
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=20260728171710.a968591ceea5782270dffcee@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=nico.pache@linux.dev \
--cc=noren@nvidia.com \
--cc=ryan.roberts@arm.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@suse.cz \
--cc=ziy@nvidia.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.