Re: [PATCH v2 0/2] mm/compaction: stop repeating failed async compaction on every THP fault

[Qiliang Yuan <qiliang.yuan@linux.dev>]

On 11/10/26 15:13, Vlastimil Babka wrote:
> The series was nacked twice by senior maintainers. Due to dealing with
> urgent issues [1] we might perhaps find time later to see if it reports a
> real issue, and in that case fix it ourselves. We have currently no time to
> help those who need AI assistance to contribute instead of having own knowledge.
>
> [1]
> https://lore.kernel.org/linux-mm/a2f584f6-e382-4876-aa6d-d5a34de6ee59@kernel.org/

I'm only spending time on this because it gets in the way of AI
training and inference, which long-term pin large buffers for RDMA.
Mooncake, the KV cache store used with vLLM and SGLang, hit it with
8 ranks x 190GB taking ~38 minutes to register. The stall and the
numbers are real, also measured on my own test setup.

Async failures have not been deferred since commit 66199712e9ee ("mm:
page allocator: do not call direct reclaim for THP allocations while
compaction is deferred"), which explained:

	/*
	 * As async compaction considers a subset of pageblocks, only
	 * defer if the failure was a sync compaction failure.
	 */

That still holds, so the series has no Fixes tag: it isn't a bug in
that commit. What the rule doesn't cover is long-term pinned memory,
much less common in 2012, where async fails the same way on every
fault and is never deferred. The series leaves sync deferral as it is
and gives async a state of its own. The analysis and a reproducer are
in [2].

If you look at it later, I'm happy to test whatever you come up with.

[2] https://lore.kernel.org/r/20261110144256.3841504-1-qiliang.yuan@linux.dev

Thanks,
Qiliang