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

Michal Clapinski posted 2 patches 1 year ago
There is a newer version of this series
Documentation/admin-guide/sysctl/vm.rst | 17 +++++++++++++++++
mm/compaction.c                         | 14 ++++++++++++--
2 files changed, 29 insertions(+), 2 deletions(-)
[PATCH v3 0/2] mm/compaction: allow more aggressive proactive compaction
Posted by Michal Clapinski 1 year ago
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(-)

-- 
2.48.1.262.g85cc9f2d1e-goog
Re: [PATCH v3 0/2] mm/compaction: allow more aggressive proactive compaction
Posted by Andrew Morton 10 months, 4 weeks ago
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).
> 

I'm not seeing enthusiasm for these changes and a couple of comments
from myself remain unaddressed.  I'll drop the series - let's revisit
in the next -rc cycle, if you feel so motivated.
Re: [PATCH v3 0/2] mm/compaction: allow more aggressive proactive compaction
Posted by Andrew Morton 1 year ago
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.