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

[Vlastimil Babka <vbabka@suse.cz>]

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.