Re: [RFC PATCH v2 2/4] mm: compaction: target mTHP order for proactive compaction

[Dev Jain]

On 19/10/26 8:33 pm, Bo Zhang wrote:
> On 19/10/26 1:42 pm, Dev Jain wrote:
>> I wonder if this function should be left alone?
>>
>> compaction_proactiveness, as I understand is given as a sysfs knob to
>> ensure that the user can control how much power they want to invest into
>> compacting. So suppose the value is 20, and the highest mTHP order is
>> only 2. This gives wmark = 90 * 2 / 9 = 20. So, even if 80% of the memory
>> can serve order-2 allocations, we will still perform compaction for
>> order-2. This seems "extremely proactive" :)
> 
> Thanks a lot for looking at this closely, and you are right that the
> scaling factor is the weakest part of this patch. I called it out as an
> open question in the cover letter and I don't have a solid theoretical
> basis for the linear order/COMPACTION_HPAGE_ORDER form.
> 
> What pushed me towards scaling the watermark at all was the opposite
> problem on the measurement side: without any scaling, the order-9
> threshold is essentially never reached for a small order, so proactive
> compaction effectively never runs for order-2.
> 
> I instrumented fragmentation_score_node() for order-2 on an 8G,
> data=journal kernel-build workload and sampled it at ~100ms. On the
> unpatched kernel the order-2 score looks like this:
> 
>   order-2 score (unpatched, same workload):
>     mean      17.3
>     p90       47
>     p99       91
>     max       100
> 
>   fraction of time the score exceeds a given threshold:
>     > 90 (unscaled, the current order-9 wmark):  1.0%
>     > 20 (scaled down to order-2):              27.2%
> 
> So with the current (unscaled) watermark, the order-2 score crosses the
> trigger only 1% of the time, which in practice proactive compaction almost
> never fires for order-2.

I get it, so the workload is rapidly allocating mTHP, and kcompactd does not
kick in time, leading to direct compaction (compact_stall) or fallback.

But I think this is a tradeoff with the current design in Linux and has nothing
to do with our mTHP usecase right? Even with PMD sized THP we may have the same
problem.

I think the uncontroversial bit of your patchset is the fact that currently we
migrate large folios just to free up a 2M region. To make forward progress it
will be great if you can find a workload which gets us an improvement without
the threshold changes and we could get those patches merged first.

I am saying that because the reason you keep crossing the 90% threshold is
due to the nature of the workload and that you set 32k mTHP to always. I doubt
on a real system you will cross the threshold this rapidly since mTHP would be
mostly "madvise" and that mTHP-requiring workload wouldn't be the only workload
running.

Given that, one thing that comes to mind is this algorithm - kcompactd wakes up, sees
that the threshold got crossed again, which means it woke up too late. So
it should manipulate the threshold or its wake up time. We need a signal to
say that the mTHP allocation is too abundant and we need background compaction
more frequently.

This algorithm may be in contradiction with the sysctl ... so instead of changing
the threshold, we could lower the wakeup time.

This is similar to how the pcp list changes its threshold if too much allocation
is happening.
> 
> That said, your example shows the linear scaling clearly overshoots in
> the other direction: a scaled wmark of ~20 can keep compacting while a
> large fraction of memory is already usable, which is not what the
> proactiveness knob is supposed to express. So I agree the current formula
> is not the right answer.
> 
> I'd appreciate your thoughts on the direction here. A couple of options
> I can see:
> 
>   1. Leave fragmentation_score_wmark() alone and instead make the score
>      itself order-aware / normalized, so that a given proactiveness value
>      maps to a comparable amount of work regardless of the target order.
>      This keeps the knob's meaning intact.

The challenge is the normalization algorithm, the problem is that there is
nothing we can deduce apart from the fact that
frag_score (order x) <= frag_score (order y) where x <= y.

> 
>   2. Keep scaling the watermark but with a floor / non-linear mapping so
>      it cannot collapse to a value that triggers when memory is clearly
>      sufficient.
> 
> I haven't settled on either yet and would rather hear which direction you
> think makes more sense before reworking it.
> 
> Also, thanks for the review on patch 4 -- good to know the
> costly/non-costly split seems like a reasonable compromise.
> 
> Thanks,
> Bo