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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <175ea8ba-e681-4de4-811e-c623acfb5e3a@suse.cz>
Date: Mon, 27 Jan 2025 15:13:21 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Michał Cłapiński <mclapinski@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
 Nitin Gupta <nigupta@...dia.com>, Pasha Tatashin <tatashin@...gle.com>,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] mm/compaction: remove low watermark cap for proactive
 compaction

On 1/27/25 14:31, Michał Cłapiński wrote:
> On Mon, Jan 27, 2025 at 11:38 AM Vlastimil Babka <vbabka@...e.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.