The patch titled
Subject: mm/compaction: remove low watermark cap for proactive compaction
has been added to the -mm mm-unstable branch. Its filename is
mm-compaction-remove-low-watermark-cap-for-proactive-compaction.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-compaction-remove-low-watermark-cap-for-proactive-compaction.patch
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Michal Clapinski <mclapinski@xxxxxxxxxx>
Subject: mm/compaction: remove low watermark cap for proactive compaction
Date: Mon, 27 Jan 2025 22:50:19 +0100
Patch series "mm/compaction: allow more aggressive proactive compaction",
v3.
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.
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). Let's define the difference between high and low watermarks as
leeway. Before these changes, the minimum possible value for low
watermark was 5 and the leeway was hardcoded to 10 (so minimum possible
value for high watermark was 15).
This patch (of 3):
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.
Link: https://lkml.kernel.org/r/20250127215020.4023545-2-mclapinski@xxxxxxxxxx
Signed-off-by: Michal Clapinski <mclapinski@xxxxxxxxxx>
Cc: Vlastimil Babka <vbabka@xxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/compaction.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/compaction.c~mm-compaction-remove-low-watermark-cap-for-proactive-compaction
+++ a/mm/compaction.c
@@ -2256,7 +2256,7 @@ static unsigned int fragmentation_score_
* 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);
}
_
Patches currently in -mm which might be from mclapinski@xxxxxxxxxx are
mm-compaction-remove-low-watermark-cap-for-proactive-compaction.patch
mm-compaction-make-proactive-compaction-high-watermark-configurable-via-sysctl.patch
