[PATCH v2] mm/khugepaged: cap min_free_kbytes recommendation at 1 GiB

[PATCH v2] mm/khugepaged: cap min_free_kbytes recommendation at 1 GiB

[Nimrod Oren]

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.

Link: https://lore.kernel.org/r/20260716173504.760369-1-noren@nvidia.com/
Suggested-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Nimrod Oren <noren@nvidia.com>
---
v2:
* Use a named constant for the cap.
* Drop explicit linux/sizes.h include.
* Update min_free_kbytes documentation.

v1:
* Cap the final recommendation at 1 GiB as suggested by Lorenzo.
https://lore.kernel.org/r/20260728202014.2517142-1-noren@nvidia.com/

RFC v1:
https://lore.kernel.org/r/20260716173504.760369-1-noren@nvidia.com/
---
 Documentation/admin-guide/sysctl/vm.rst | 8 ++++++++
 mm/khugepaged.c                         | 7 ++++++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst
index 5b318d17aa4b..c0c925e6f504 100644
--- a/Documentation/admin-guide/sysctl/vm.rst
+++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -539,6 +539,14 @@ watermark[WMARK_MIN] value for each lowmem zone in the system.
 Each lowmem zone gets a number of reserved free pages based
 proportionally on its size.
 
+When Transparent Hugepage (THP) support is enabled through global or
+per-size controls, the kernel may raise this value automatically to
+help keep pageblocks free and reduce fragmentation for THP allocations.
+The automatic recommendation cannot exceed 5% of low memory or 1 GiB,
+whichever is lower.  This limit applies only to the automatic
+recommendation and does not constrain a higher value written by
+userspace.
+
 Some minimal amount of memory is needed to satisfy PF_MEMALLOC
 allocations; if you set this to lower than 1024KB, your system will
 become subtly broken, and prone to deadlock under high loads.
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index f49a6710933b..a8fc061d2488 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -101,6 +101,7 @@ static DEFINE_READ_MOSTLY_HASHTABLE(mm_slots_hash, MM_SLOTS_HASH_BITS);
 
 static struct kmem_cache *mm_slot_cache __ro_after_init;
 
+#define THP_MIN_FREE_MAX_PAGES		(SZ_1G / PAGE_SIZE)
 #define KHUGEPAGED_MIN_MTHP_ORDER	2
 
 struct collapse_control {
@@ -3120,9 +3121,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 allow the THP recommendation to exceed 5% of lowmem or an
+	 * absolute cap, whichever is smaller.
+	 */
 	recommended_min = min(recommended_min,
 			      (unsigned long) nr_free_buffer_pages() / 20);
+	recommended_min = min(recommended_min, THP_MIN_FREE_MAX_PAGES);
 	recommended_min <<= (PAGE_SHIFT-10);
 
 	if (recommended_min > min_free_kbytes) {
-- 
2.45.0

Re: [PATCH v2] mm/khugepaged: cap min_free_kbytes recommendation at 1 GiB

[Kiryl Shutsemau]

On Mon, Aug 31, 2026 at 10:56:35AM +0300, Nimrod Oren 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.

I am not against an upper limit for min_free_kbytes, but I think the
root cause of the problem you see is the size of the page block.

We at Meta switched to 2M page blocks on 64k ARMs recently, targeting 2M
mTHPs. A 512M pageblock is not practical.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

Re: [PATCH v2] mm/khugepaged: cap min_free_kbytes recommendation at 1 GiB

[Lorenzo Stoakes (ARM)]

On Mon, Aug 31, 2026 at 09:47:29AM +0100, Kiryl Shutsemau wrote:
> On Mon, Aug 31, 2026 at 10:56:35AM +0300, Nimrod Oren 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.
>
> I am not against an upper limit for min_free_kbytes, but I think the
> root cause of the problem you see is the size of the page block.
>
> We at Meta switched to 2M page blocks on 64k ARMs recently, targeting 2M
> mTHPs. A 512M pageblock is not practical.

I mean we do keep looping around on these things as 64 KiB page size is
fundamentally a big problem for the pageblock model :)

I don't love the idea of just making page blocks arbitrary smaller for
higher page table size, because hey the intent is to get a PMD-sized thing.

So really I think to do it 'properly' you'd need to rework how that whole
thing functions.

For me the approach here is a practical trade-off - if the intent is to cap
at a sensible value, then just cap at a sensible value.

>
> --
>   Kiryl Shutsemau / Kirill A. Shutemov

--
Cheers, Lorenzo

Re: [PATCH v2] mm/khugepaged: cap min_free_kbytes recommendation at 1 GiB

[Lorenzo Stoakes (ARM)]

On Mon, Aug 31, 2026 at 10:56:35AM +0300, Nimrod Oren 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.
>
> Link: https://lore.kernel.org/r/20260716173504.760369-1-noren@nvidia.com/
> Suggested-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> Signed-off-by: Nimrod Oren <noren@nvidia.com>

I do think this is a practical way of preventing runaway increase of reserves.

In the long run we need to rework the pageblock model I think, but this is
a reasonable way forward in the short-medium term.

Obviously I defer to David and the community on this if they think this is
horrible, then let's not.

But I do worry that we'll carry on with unworkably huge reserves on 64 KiB
page size while rejecting every way out until pageblocks are _entirely_
reworked to account for this (probably the long term solution).

So I think this the least-worst approach of those proposed so far for now
:) Therefore:

Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>

> ---
> v2:
> * Use a named constant for the cap.
> * Drop explicit linux/sizes.h include.
> * Update min_free_kbytes documentation.
>
> v1:
> * Cap the final recommendation at 1 GiB as suggested by Lorenzo.
> https://lore.kernel.org/r/20260728202014.2517142-1-noren@nvidia.com/
>
> RFC v1:
> https://lore.kernel.org/r/20260716173504.760369-1-noren@nvidia.com/
> ---
>  Documentation/admin-guide/sysctl/vm.rst | 8 ++++++++
>  mm/khugepaged.c                         | 7 ++++++-
>  2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst
> index 5b318d17aa4b..c0c925e6f504 100644
> --- a/Documentation/admin-guide/sysctl/vm.rst
> +++ b/Documentation/admin-guide/sysctl/vm.rst
> @@ -539,6 +539,14 @@ watermark[WMARK_MIN] value for each lowmem zone in the system.
>  Each lowmem zone gets a number of reserved free pages based
>  proportionally on its size.
>
> +When Transparent Hugepage (THP) support is enabled through global or
> +per-size controls, the kernel may raise this value automatically to
> +help keep pageblocks free and reduce fragmentation for THP allocations.
> +The automatic recommendation cannot exceed 5% of low memory or 1 GiB,
> +whichever is lower.  This limit applies only to the automatic
> +recommendation and does not constrain a higher value written by
> +userspace.
> +
>  Some minimal amount of memory is needed to satisfy PF_MEMALLOC
>  allocations; if you set this to lower than 1024KB, your system will
>  become subtly broken, and prone to deadlock under high loads.
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index f49a6710933b..a8fc061d2488 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -101,6 +101,7 @@ static DEFINE_READ_MOSTLY_HASHTABLE(mm_slots_hash, MM_SLOTS_HASH_BITS);
>
>  static struct kmem_cache *mm_slot_cache __ro_after_init;
>
> +#define THP_MIN_FREE_MAX_PAGES		(SZ_1G / PAGE_SIZE)
>  #define KHUGEPAGED_MIN_MTHP_ORDER	2
>
>  struct collapse_control {
> @@ -3120,9 +3121,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 allow the THP recommendation to exceed 5% of lowmem or an
> +	 * absolute cap, whichever is smaller.
> +	 */
>  	recommended_min = min(recommended_min,
>  			      (unsigned long) nr_free_buffer_pages() / 20);
> +	recommended_min = min(recommended_min, THP_MIN_FREE_MAX_PAGES);
>  	recommended_min <<= (PAGE_SHIFT-10);
>
>  	if (recommended_min > min_free_kbytes) {
> --
> 2.45.0
>

--
Cheers, Lorenzo

Re: [PATCH v2] mm/khugepaged: cap min_free_kbytes recommendation at 1 GiB

[Lance Yang]

On 2026/8/31 15:56, Nimrod Oren 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.

Sorry, I haven't been following the previous discussion.

One nit: why 1 GiB? It feels a bit arbitrary to me ...

Re: [PATCH v2] mm/khugepaged: cap min_free_kbytes recommendation at 1 GiB

[Michal Hocko]

On Mon 31-08-26 10:56:35, Nimrod Oren 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.

I would argue that the whole model of increasing min_free_kbytes for THP
is wrong. This will trigger memory reclaim sooner and make the THP
availability more likely but this was at times where we didn't have
pro-active compaction and many changes in the compaction. So is this
actually needed in general resp. only large pageblocks systems?

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2] mm/khugepaged: cap min_free_kbytes recommendation at 1 GiB

[Lorenzo Stoakes (ARM)]

On Mon, Aug 31, 2026 at 11:20:30AM +0200, Michal Hocko wrote:
> On Mon 31-08-26 10:56:35, Nimrod Oren 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.
>
> I would argue that the whole model of increasing min_free_kbytes for THP
> is wrong. This will trigger memory reclaim sooner and make the THP
> availability more likely but this was at times where we didn't have
> pro-active compaction and many changes in the compaction. So is this
> actually needed in general resp. only large pageblocks systems?

Ohh even better :)

I did find it strange that we increased accordingly.

I'm more than happy to see this just die altogether if people agree that's
a sensible way forward...

>
> --
> Michal Hocko
> SUSE Labs

--
Cheers, Lorenzo

Re: [PATCH v2] mm/khugepaged: cap min_free_kbytes recommendation at 1 GiB

[Zi Yan]

On 31 Aug 2026, at 5:34, Lorenzo Stoakes (ARM) wrote:

> On Mon, Aug 31, 2026 at 11:20:30AM +0200, Michal Hocko wrote:
>> On Mon 31-08-26 10:56:35, Nimrod Oren 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.
>>
>> I would argue that the whole model of increasing min_free_kbytes for THP
>> is wrong. This will trigger memory reclaim sooner and make the THP
>> availability more likely but this was at times where we didn't have
>> pro-active compaction and many changes in the compaction. So is this
>> actually needed in general resp. only large pageblocks systems?
>
> Ohh even better :)
>
> I did find it strange that we increased accordingly.
>
> I'm more than happy to see this just die altogether if people agree that's
> a sensible way forward...

It sounds reasonable to me.

My first reaction was that THP generation might be hurt due to fewer
free pages. But probably the extra min_free_kbytes just moves reclaim earlier,
like Michal said.

After removing this automatic min_free_kbytes bump, user can retain the old
behavior by setting a higher min_free_kbytes at boot time.

Best Regards,
Yan, Zi

Re: [PATCH v2] mm/khugepaged: cap min_free_kbytes recommendation at 1 GiB

[Zi Yan]

On 31 Aug 2026, at 5:00, Lance Yang wrote:

> On 2026/8/31 15:56, Nimrod Oren 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.
>
> Sorry, I haven't been following the previous discussion.
>
> One nit: why 1 GiB? It feels a bit arbitrary to me ...

It is. Just better than 5.5GiB in the existing configuration.

Best Regards,
Yan, Zi

Re: [PATCH v2] mm/khugepaged: cap min_free_kbytes recommendation at 1 GiB

[Lorenzo Stoakes (ARM)]

On Mon, Aug 31, 2026 at 11:00:13AM -0400, Zi Yan wrote:
> On 31 Aug 2026, at 5:34, Lorenzo Stoakes (ARM) wrote:
>
> > On Mon, Aug 31, 2026 at 11:20:30AM +0200, Michal Hocko wrote:
> >> On Mon 31-08-26 10:56:35, Nimrod Oren 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.
> >>
> >> I would argue that the whole model of increasing min_free_kbytes for THP
> >> is wrong. This will trigger memory reclaim sooner and make the THP
> >> availability more likely but this was at times where we didn't have
> >> pro-active compaction and many changes in the compaction. So is this
> >> actually needed in general resp. only large pageblocks systems?
> >
> > Ohh even better :)
> >
> > I did find it strange that we increased accordingly.
> >
> > I'm more than happy to see this just die altogether if people agree that's
> > a sensible way forward...
>
> It sounds reasonable to me.
>
> My first reaction was that THP generation might be hurt due to fewer
> free pages. But probably the extra min_free_kbytes just moves reclaim earlier,
> like Michal said.
>
> After removing this automatic min_free_kbytes bump, user can retain the old
> behavior by setting a higher min_free_kbytes at boot time.

Nimrod - care to send a patch to just yank this min_free_kbytes change for
thp out? :)

This solves your problem another way and is neater overall.

>
> Best Regards,
> Yan, Zi

--
Cheers, Lorenzo

Re: [PATCH v2] mm/khugepaged: cap min_free_kbytes recommendation at 1 GiB

[Nimrod Oren]

On 31/08/2026 18:59, Lorenzo Stoakes (ARM) wrote:
> On Mon, Aug 31, 2026 at 11:00:13AM -0400, Zi Yan wrote:
>> On 31 Aug 2026, at 5:34, Lorenzo Stoakes (ARM) wrote:
>>> On Mon, Aug 31, 2026 at 11:20:30AM +0200, Michal Hocko wrote:
>>>> I would argue that the whole model of increasing min_free_kbytes for THP
>>>> is wrong. This will trigger memory reclaim sooner and make the THP
>>>> availability more likely but this was at times where we didn't have
>>>> pro-active compaction and many changes in the compaction. So is this
>>>> actually needed in general resp. only large pageblocks systems?
>>>
>>> Ohh even better :)
>>>
>>> I did find it strange that we increased accordingly.
>>>
>>> I'm more than happy to see this just die altogether if people agree that's
>>> a sensible way forward...
>>
>> It sounds reasonable to me.
>>
>> My first reaction was that THP generation might be hurt due to fewer
>> free pages. But probably the extra min_free_kbytes just moves reclaim earlier,
>> like Michal said.
>>
>> After removing this automatic min_free_kbytes bump, user can retain the old
>> behavior by setting a higher min_free_kbytes at boot time.
> 
> Nimrod - care to send a patch to just yank this min_free_kbytes change for
> thp out? :)
> 
> This solves your problem another way and is neater overall.

Absolutely :)
Thanks for the suggestion!