[PATCH 0/2] mm/compaction: allow more aggressive proactive compaction

[PATCH 0/2] mm/compaction: allow more aggressive proactive compaction

[Michal Clapinski]

Our goal is to keep memory usage of a VM low on the host. For that
reason, we use free page reporting which by default reports free pages
of order 9 and larger to the host to be freed. The feature works well
only if the memory in the guest is not fragmented below pages of order
9. Proactive compaction can be reused to achieve defragmentation after
some parameter tweaking.

Michal Clapinski (2):
  mm/compaction: remove low watermark cap for proactive compaction
  mm/compaction: expose a new param for proactive compaction

 mm/compaction.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

-- 
2.48.1.262.g85cc9f2d1e-goog

[PATCH 1/2] mm/compaction: remove low watermark cap for proactive compaction

[Michal Clapinski]

Previously a min cap of 5 has been set in the commit introducing
proactive compaction. This was to make sure users don't hurt themselves
by setting the proactiveness to 100 and making their system
unresponsive. But the compaction mechanism has a backoff mechanism that
will sleep for 30s if no progress is made, so I don't see a significant
risk here. My system (20GB of memory) has been perfectly fine with
proactiveness set to 100 and leeway set to 0.

Signed-off-by: Michal Clapinski <mclapinski@google.com>
---
 mm/compaction.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index a2b16b08cbbff..29524242a16ef 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -2253,7 +2253,7 @@ static unsigned int fragmentation_score_wmark(bool low)
 	 * activity in case a user sets the proactiveness tunable
 	 * close to 100 (maximum).
 	 */
-	wmark_low = max(100U - sysctl_compaction_proactiveness, 5U);
+	wmark_low = 100U - sysctl_compaction_proactiveness;
 	return low ? wmark_low : min(wmark_low + 10, 100U);
 }
 
-- 
2.48.1.262.g85cc9f2d1e-goog

[PATCH 2/2] mm/compaction: expose a new param for proactive compaction

[Michal Clapinski]

Expose the diff between low and high watermark as a sysctl var.

Signed-off-by: Michal Clapinski <mclapinski@google.com>
---
 mm/compaction.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 29524242a16ef..fd546b797e544 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1921,6 +1921,7 @@ static int sysctl_compact_unevictable_allowed __read_mostly = CONFIG_COMPACT_UNE
  * background. It takes values in the range [0, 100].
  */
 static unsigned int __read_mostly sysctl_compaction_proactiveness = 20;
+static unsigned int __read_mostly sysctl_compaction_proactiveness_leeway = 10;
 static int sysctl_extfrag_threshold = 500;
 static int __read_mostly sysctl_compact_memory;
 
@@ -2254,7 +2255,7 @@ static unsigned int fragmentation_score_wmark(bool low)
 	 * close to 100 (maximum).
 	 */
 	wmark_low = 100U - sysctl_compaction_proactiveness;
-	return low ? wmark_low : min(wmark_low + 10, 100U);
+	return low ? wmark_low : min(wmark_low + sysctl_compaction_proactiveness_leeway, 100U);
 }
 
 static bool should_proactive_compact_node(pg_data_t *pgdat)
@@ -3314,6 +3315,15 @@ static struct ctl_table vm_compaction[] = {
 		.extra1		= SYSCTL_ZERO,
 		.extra2		= SYSCTL_ONE_HUNDRED,
 	},
+	{
+		.procname	= "compaction_proactiveness_leeway",
+		.data		= &sysctl_compaction_proactiveness_leeway,
+		.maxlen		= sizeof(sysctl_compaction_proactiveness_leeway),
+		.mode		= 0644,
+		.proc_handler	= compaction_proactiveness_sysctl_handler,
+		.extra1		= SYSCTL_ZERO,
+		.extra2		= SYSCTL_ONE_HUNDRED,
+	},
 	{
 		.procname	= "extfrag_threshold",
 		.data		= &sysctl_extfrag_threshold,
-- 
2.48.1.262.g85cc9f2d1e-goog

Re: [PATCH 1/2] mm/compaction: remove low watermark cap for proactive compaction

[Pasha Tatashin]

On Fri, Jan 24, 2025 at 1:21 PM Michal Clapinski <mclapinski@google.com> wrote:
>
> Previously a min cap of 5 has been set in the commit introducing
> proactive compaction. This was to make sure users don't hurt themselves
> by setting the proactiveness to 100 and making their system
> unresponsive. But the compaction mechanism has a backoff mechanism that
> will sleep for 30s if no progress is made, so I don't see a significant
> risk here. My system (20GB of memory) has been perfectly fine with
> proactiveness set to 100 and leeway set to 0.
>
> Signed-off-by: Michal Clapinski <mclapinski@google.com>

Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>

Thank you,
Pasha

Re: [PATCH 2/2] mm/compaction: expose a new param for proactive compaction

[Pasha Tatashin]

Subject should be something like:

mm/compaction: Make proactive compaction high watermark configurable via sysctl

On Fri, Jan 24, 2025 at 1:21 PM Michal Clapinski <mclapinski@google.com> wrote:
>
> Expose the diff between low and high watermark as a sysctl var.

Please expand, for example:

Currently, the difference between the low and high watermarks for
proactive compaction is hardcoded to 10. This hardcoded difference is
too large for free page reporting to work correctly.

Add a new sysctl, `compaction_proactiveness_leeway`, to control the
difference between the low and high watermarks.

Pasha

>
> Signed-off-by: Michal Clapinski <mclapinski@google.com>
> ---
>  mm/compaction.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 29524242a16ef..fd546b797e544 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -1921,6 +1921,7 @@ static int sysctl_compact_unevictable_allowed __read_mostly = CONFIG_COMPACT_UNE
>   * background. It takes values in the range [0, 100].
>   */
>  static unsigned int __read_mostly sysctl_compaction_proactiveness = 20;
> +static unsigned int __read_mostly sysctl_compaction_proactiveness_leeway = 10;
>  static int sysctl_extfrag_threshold = 500;
>  static int __read_mostly sysctl_compact_memory;
>
> @@ -2254,7 +2255,7 @@ static unsigned int fragmentation_score_wmark(bool low)
>          * close to 100 (maximum).
>          */
>         wmark_low = 100U - sysctl_compaction_proactiveness;
> -       return low ? wmark_low : min(wmark_low + 10, 100U);
> +       return low ? wmark_low : min(wmark_low + sysctl_compaction_proactiveness_leeway, 100U);
>  }
>
>  static bool should_proactive_compact_node(pg_data_t *pgdat)
> @@ -3314,6 +3315,15 @@ static struct ctl_table vm_compaction[] = {
>                 .extra1         = SYSCTL_ZERO,
>                 .extra2         = SYSCTL_ONE_HUNDRED,
>         },
> +       {
> +               .procname       = "compaction_proactiveness_leeway",
> +               .data           = &sysctl_compaction_proactiveness_leeway,
> +               .maxlen         = sizeof(sysctl_compaction_proactiveness_leeway),
> +               .mode           = 0644,
> +               .proc_handler   = compaction_proactiveness_sysctl_handler,
> +               .extra1         = SYSCTL_ZERO,
> +               .extra2         = SYSCTL_ONE_HUNDRED,
> +       },
>         {
>                 .procname       = "extfrag_threshold",
>                 .data           = &sysctl_extfrag_threshold,
> --
> 2.48.1.262.g85cc9f2d1e-goog
>
>

Re: [PATCH 0/2] mm/compaction: allow more aggressive proactive compaction

[Vlastimil Babka]

On 1/24/25 19:21, Michal Clapinski wrote:
> Our goal is to keep memory usage of a VM low on the host. For that
> reason, we use free page reporting which by default reports free pages
> of order 9 and larger to the host to be freed. The feature works well
> only if the memory in the guest is not fragmented below pages of order
> 9. Proactive compaction can be reused to achieve defragmentation after
> some parameter tweaking.

Could you explain the tweaking more in the cover letter? You seem to be
allowing proactive compaction to kick in more aggressively but at the same
time lower the leeway to make it finish quicker?

Thanks.

> Michal Clapinski (2):
>   mm/compaction: remove low watermark cap for proactive compaction
>   mm/compaction: expose a new param for proactive compaction
> 
>  mm/compaction.c | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 

Re: [PATCH 1/2] mm/compaction: remove low watermark cap for proactive compaction

[Vlastimil Babka]

On 1/24/25 19:21, Michal Clapinski wrote:
> Previously a min cap of 5 has been set in the commit introducing
> proactive compaction. This was to make sure users don't hurt themselves
> by setting the proactiveness to 100 and making their system
> unresponsive. But the compaction mechanism has a backoff mechanism that
> will sleep for 30s if no progress is made, so I don't see a significant
> risk here. My system (20GB of memory) has been perfectly fine with
> proactiveness set to 100 and leeway set to 0.

What if you don't set the leeway to 0? In other words, should we keep the
cap in some sense but make it depend on the leeway?

> Signed-off-by: Michal Clapinski <mclapinski@google.com>
> ---
>  mm/compaction.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index a2b16b08cbbff..29524242a16ef 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -2253,7 +2253,7 @@ static unsigned int fragmentation_score_wmark(bool low)
>  	 * activity in case a user sets the proactiveness tunable
>  	 * close to 100 (maximum).
>  	 */
> -	wmark_low = max(100U - sysctl_compaction_proactiveness, 5U);
> +	wmark_low = 100U - sysctl_compaction_proactiveness;
>  	return low ? wmark_low : min(wmark_low + 10, 100U);
>  }
>  

Re: [PATCH 2/2] mm/compaction: expose a new param for proactive compaction

[Vlastimil Babka]

On 1/25/25 17:20, Pasha Tatashin wrote:
> Subject should be something like:
> 
> mm/compaction: Make proactive compaction high watermark configurable via sysctl
> 
> On Fri, Jan 24, 2025 at 1:21 PM Michal Clapinski <mclapinski@google.com> wrote:
>>
>> Expose the diff between low and high watermark as a sysctl var.
> 
> Please expand, for example:
> 
> Currently, the difference between the low and high watermarks for
> proactive compaction is hardcoded to 10. This hardcoded difference is
> too large for free page reporting to work correctly.
> 
> Add a new sysctl, `compaction_proactiveness_leeway`, to control the
> difference between the low and high watermarks.

Yeah, also please update Documentation/admin-guide/sysctl/vm.rst accordingly.

Thanks, Vlastimil

Re: [PATCH 1/2] mm/compaction: remove low watermark cap for proactive compaction

[Michał Cłapiński]

On Mon, Jan 27, 2025 at 11:38 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>
> On 1/24/25 19:21, Michal Clapinski wrote:
> > Previously a min cap of 5 has been set in the commit introducing
> > proactive compaction. This was to make sure users don't hurt themselves
> > by setting the proactiveness to 100 and making their system
> > unresponsive. But the compaction mechanism has a backoff mechanism that
> > will sleep for 30s if no progress is made, so I don't see a significant
> > risk here. My system (20GB of memory) has been perfectly fine with
> > proactiveness set to 100 and leeway set to 0.

> What if you don't set the leeway to 0?

When the fragmentation score (lower is better) gets larger than the
high watermark, proactive compaction kicks in. Compaction stops when
the score goes below the low watermark (or no progress is made and
backoff kicks in). Leeway is the difference between low and high
watermarks. So the bigger the leeway, the longer we have to wait for
proactive compaction to kick in. Memory usage on the host would also
look more like a sawtooth wave (slowly creeping up then sharp drop).

I set the leeway to 0 in this example because that's the most
aggressive configuration. My system can't reach a fragmentation score
of 0, so it tries to do compaction as often as possible.

> In other words, should we keep the cap in some sense but make it depend on the leeway?

I could do something like
wmark_low = max(100U - sysctl_compaction_proactiveness,
min(sysctl_compaction_proactiveness_leeway, 5U));
and it would have the benefit of not changing the behavior of
proactive compaction for current users. However, it would make it
impossible to have a small low watermark with the default leeway.
That's okay in my case but do we want to create those restrictions for
the future users?


>
>
> > Signed-off-by: Michal Clapinski <mclapinski@google.com>
> > ---
> >  mm/compaction.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/mm/compaction.c b/mm/compaction.c
> > index a2b16b08cbbff..29524242a16ef 100644
> > --- a/mm/compaction.c
> > +++ b/mm/compaction.c
> > @@ -2253,7 +2253,7 @@ static unsigned int fragmentation_score_wmark(bool low)
> >        * activity in case a user sets the proactiveness tunable
> >        * close to 100 (maximum).
> >        */
> > -     wmark_low = max(100U - sysctl_compaction_proactiveness, 5U);
> > +     wmark_low = 100U - sysctl_compaction_proactiveness;
> >       return low ? wmark_low : min(wmark_low + 10, 100U);
> >  }
> >
>

Re: [PATCH 1/2] mm/compaction: remove low watermark cap for proactive compaction

[Vlastimil Babka]

On 1/27/25 14:31, Michał Cłapiński wrote:
> On Mon, Jan 27, 2025 at 11:38 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>>
>> On 1/24/25 19:21, Michal Clapinski wrote:
>> > Previously a min cap of 5 has been set in the commit introducing
>> > proactive compaction. This was to make sure users don't hurt themselves
>> > by setting the proactiveness to 100 and making their system
>> > unresponsive. But the compaction mechanism has a backoff mechanism that
>> > will sleep for 30s if no progress is made, so I don't see a significant
>> > risk here. My system (20GB of memory) has been perfectly fine with
>> > proactiveness set to 100 and leeway set to 0.
> 
>> What if you don't set the leeway to 0?
> 
> When the fragmentation score (lower is better) gets larger than the
> high watermark, proactive compaction kicks in. Compaction stops when
> the score goes below the low watermark (or no progress is made and
> backoff kicks in). Leeway is the difference between low and high
> watermarks. So the bigger the leeway, the longer we have to wait for
> proactive compaction to kick in. Memory usage on the host would also
> look more like a sawtooth wave (slowly creeping up then sharp drop).

Oh I see, I got the direction opposite mentally, when responding.

But that writeup could go in some form to the patch/cover letter :)

> I set the leeway to 0 in this example because that's the most
> aggressive configuration. My system can't reach a fragmentation score
> of 0, so it tries to do compaction as often as possible.

And thus thought leeway of 0 means less agressive.

>> In other words, should we keep the cap in some sense but make it depend on the leeway?
> 
> I could do something like
> wmark_low = max(100U - sysctl_compaction_proactiveness,
> min(sysctl_compaction_proactiveness_leeway, 5U));
> and it would have the benefit of not changing the behavior of
> proactive compaction for current users. However, it would make it
> impossible to have a small low watermark with the default leeway.
> That's okay in my case but do we want to create those restrictions for
> the future users?

With that, the restriction seems unnecessary. Thanks.