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