mbox series

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

Message ID 20250127215020.4023545-1-mclapinski@google.com (mailing list archive)
Headers show
Series mm/compaction: allow more aggressive proactive compaction | expand

Message

Michał Cłapiński Jan. 27, 2025, 9:50 p.m. UTC
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).

v3: Remove gerrit ids from commit msgs.
v2: Change commit msgs and document the new sysctl.

Michal Clapinski (2):
  mm/compaction: remove low watermark cap for proactive compaction
  mm/compaction: make proactive compaction high watermark configurable
    via sysctl

 Documentation/admin-guide/sysctl/vm.rst | 17 +++++++++++++++++
 mm/compaction.c                         | 14 ++++++++++++--
 2 files changed, 29 insertions(+), 2 deletions(-)

Comments

Andrew Morton Jan. 28, 2025, 1:07 a.m. UTC | #1
On Mon, 27 Jan 2025 22:50:18 +0100 Michal Clapinski <mclapinski@google.com> 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.
> 
> 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).
> 

It would be helpful to let us know the benefits of this change for our
users.  Some reasonably detailed real-world before-and-after narrative
would suit, please.