Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings

[Shakeel Butt <shakeel.butt@linux.dev>]

On Tue, Jan 07, 2025 at 09:34:49AM +0100, David Hildenbrand wrote:
> On 06.01.25 19:17, Shakeel Butt wrote:
> > On Mon, Jan 06, 2025 at 11:19:42AM +0100, Miklos Szeredi wrote:
> > > On Fri, 3 Jan 2025 at 21:31, David Hildenbrand <david@redhat.com> wrote:
> > > > In any case, having movable pages be turned unmovable due to persistent
> > > > writaback is something that must be fixed, not worked around. Likely a
> > > > good topic for LSF/MM.
> > > 
> > > Yes, this seems a good cross fs-mm topic.
> > > 
> > > So the issue discussed here is that movable pages used for fuse
> > > page-cache cause a problems when memory needs to be compacted. The
> > > problem is either that
> > > 
> > >   - the page is skipped, leaving the physical memory block unmovable
> > > 
> > >   - the compaction is blocked for an unbounded time
> > > 
> > > While the new AS_WRITEBACK_INDETERMINATE could potentially make things
> > > worse, the same thing happens on readahead, since the new page can be
> > > locked for an indeterminate amount of time, which can also block
> > > compaction, right?
> 
> Yes, as memory hotplug + virtio-mem maintainer my bigger concern is these
> pages residing in ZONE_MOVABLE / MIGRATE_CMA areas where there *must not be
> unmovable pages ever*. Not triggered by an untrusted source, not triggered
> by an trusted source.
> 
> It's a violation of core-mm principles.

The "must not be unmovable pages ever" is a very strong statement and we
are violating it today and will keep violating it in future. Any
page/folio under lock or writeback or have reference taken or have been
isolated from their LRU is unmovable (most of the time for small period
of time). These operations are being done all over the place in kernel.
Miklos gave an example of readahead. The per-CPU LRU caches are another
case where folios can get stuck for long period of time. Reclaim and
compaction can isolate a lot of folios that they need to have
too_many_isolated() checks. So, "must not be unmovable pages ever" is
impractical.

The point is that, yes we should aim to improve things but in iterations
and "must not be unmovable pages ever" is not something we can achieve
in one step. Though I doubt that state is practically achievable and to
me something like a bound (time or amount) on the transient unmovable
folios is more practical.