Re: [PATCH] mm/compaction: do not break pages whose order is larger than target order

[Wenchao Hao <haowenchao22@gmail.com>]

On Fri, Apr 25, 2025 at 11:32 PM Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> On Fri, Apr 25, 2025 at 10:28:42PM +0800, Wenchao Hao wrote:
> > On Fri, Apr 25, 2025 at 3:42 AM Johannes Weiner <hannes@cmpxchg.org> wrote:
> > >
> > > On Thu, Apr 24, 2025 at 11:38:15PM +0800, Wenchao Hao wrote:
> > > > When scanning free pages for memory compaction, if the compaction target
> > > > order is explicitly specified, do not split pages in buddy whose order
> > > > are larger than compaction target order.
> > >
> > > Have you observed this to be an issue in practice?
> > >
> > > compact_finished() would have bailed if such a page had existed.
> > >
> >
> > Yes, when proactive memory compaction is enabled, there may be situations
> > where the order of isolated free pages is greater than the compaction
> > requested order, and compact_finished() will return continue.
>
> proactive compaction has an order of -1?

The order in struct compact_control is not directly related to
proactive compaction.

I just added a check here, if the compaction is awakened by wakeup_kcompactd()
and the target order of compaction is set, the free folios larger than
the target order
will not be split when isolating the free pages.

The following scenarios will appear when there are free pages larger
than the target
order of compaction but compact_finished() will return continue:

1. proactive compaction is enabled, kcompactd is awakened for compaction
2. the defrag_mode you added, __compact_finished() will return continue if
     the number of pageblocks size folios is smaller than watermark