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

[Bo Zhang]

On 20/10/26 12:18 pm, Dev Jain wrote:
> 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.

Agreed, the underlying "kcompactd reacts too late" tradeoff isn't specific to
mTHP. mTHP just makes it easier to hit because the allocations are frequent
and small.

> 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.

That makes sense to me, and I'm happy to split it this way - get the
uncontroversial "don't migrate folios that already satisfy the target" part
in first, separate from the threshold discussion.

One caveat: the exact shape of that part (patch 3) is tied to the cc->order
refactor Vlastimil suggested on the cover-letter thread. If proactive carries
a real target order, skip_isolation_on_order() largely covers patch 3 on its
own; if we keep order == -1, patch 3 stays as a separate check. So I'd like
to settle that refactor direction with Vlastimil first, then post the
uncontroversial part in whatever form falls out of it, to avoid reworking it
twice.

> 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.

Fair point, and I should be upfront about it: with madvise, or when higher
order fallback is acceptable, you're right that there won't be nearly as
many moments where the score is high enough to warrant compaction.

> 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.

Adjusting the wakeup time is a reasonable idea, but I have a worry that it
may not reach the actual bottleneck for small orders. Once kcompactd wakes
up it still has to pass should_proactive_compact_node(), i.e. score > wmark,
before it does any work. For order-2 the fragmentation score itself stays
small (mean ~17 in my runs, vs the unscaled order-9 wmark of ~90), so no
matter how often kcompactd wakes up, the score won't reach the threshold
and it won't compact.

I actually have a data point for this: the 100ms loop I used in the cover
letter already drives the wakeup frequency very high, and even then, when the
score is small, it simply doesn't trigger compaction - more frequent wakeups
don't help if the check that follows never passes. So waking up more often
and lowering the threshold seem to address different stages: frequency
controls how often we check, the threshold controls whether a check for a
small order can ever decide to compact. That's why I don't think wakeup
tuning alone replaces the threshold question, though I agree it could help
on top of it.

Thanks,
Bo