[LSF/MM/BPF TOPIC] Migrating the un-migratable

[LSF/MM/BPF TOPIC] Migrating the un-migratable

[David Hildenbrand]

Hi,

___GFP_MOVABLE allocations are supposed to be movable -> migratable: the 
page allocator can place them on 
MIGRATE_CMA/ZONE_MOVABLE/MIGRATE_MOVABLE areas: areas where the 
expectation is that allocations can be migrated (somewhat reliably) to 
different memory areas on demand.

Mechanisms that turn such allocations unmigratable, such as long-term 
page pinning (FOLL_LONGTERM), migrate these allocations at least out of 
MIGRATE_CMA/ZONE_MOVABLE areas first.

Ideally, we'd only perform this migration if really required (e.g., 
long-term pinning), and rather "fix" other cases to not turn allocations 
unmigratable.

However, we have some rather obscure cases that can turn migratable 
allocations effectively unmigratable for a long/indeterminate time, 
possibly controlled by unprivileged user space.

Possible effects include:
* CMA allocations failing
* Memory hotunplug not making progress
* Memory compaction not working as expected

Some cases I can fix myself [1], others are harder to tackle.

As one example, in context of FUSE we recently discovered that folios 
that are under writeback cannot be migrated, and user space in control 
of when writeback will end. Something similar can happen ->readahead() 
where user space is in charge of supplying page content. Networking 
filesystems in general seem to be prone to this as well.

As another example, failing to split large folios can prevent migration 
if memory is fragmented. XFS (IOMAP in general) refuses to split folios 
that are dirty [3]. Splitting of folios and page migration have a lot in 
common.

This session is to collect cases that are known to be problematic, and 
to start discussing possible approaches to make some of these 
un-migratable allocations migratable, or alternative strategies to deal 
with this.


[1] https://lkml.kernel.org/r/20250129115411.2077152-1-david@redhat.com
[2] 
https://lkml.kernel.org/r/CAJnrk1ZCgff6ZWmqKzBXFq5uAEbms46OexA1axWS5v-PCZFqJg@mail.gmail.com
[3] 
https://lkml.kernel.org/r/4febc035-a4ff-4afe-a9a0-d127826852a9@redhat.com

-- 
Cheers,

David / dhildenb

Re: [LSF/MM/BPF TOPIC] Migrating the un-migratable

[Frank van der Linden]

On Wed, Jan 29, 2025 at 8:10 AM David Hildenbrand <david@redhat.com> wrote:
>
> Hi,
>
> ___GFP_MOVABLE allocations are supposed to be movable -> migratable: the
> page allocator can place them on
> MIGRATE_CMA/ZONE_MOVABLE/MIGRATE_MOVABLE areas: areas where the
> expectation is that allocations can be migrated (somewhat reliably) to
> different memory areas on demand.
>
> Mechanisms that turn such allocations unmigratable, such as long-term
> page pinning (FOLL_LONGTERM), migrate these allocations at least out of
> MIGRATE_CMA/ZONE_MOVABLE areas first.
>
> Ideally, we'd only perform this migration if really required (e.g.,
> long-term pinning), and rather "fix" other cases to not turn allocations
> unmigratable.
>
> However, we have some rather obscure cases that can turn migratable
> allocations effectively unmigratable for a long/indeterminate time,
> possibly controlled by unprivileged user space.
>
> Possible effects include:
> * CMA allocations failing
> * Memory hotunplug not making progress
> * Memory compaction not working as expected
>
> Some cases I can fix myself [1], others are harder to tackle.
>
> As one example, in context of FUSE we recently discovered that folios
> that are under writeback cannot be migrated, and user space in control
> of when writeback will end. Something similar can happen ->readahead()
> where user space is in charge of supplying page content. Networking
> filesystems in general seem to be prone to this as well.
>
> As another example, failing to split large folios can prevent migration
> if memory is fragmented. XFS (IOMAP in general) refuses to split folios
> that are dirty [3]. Splitting of folios and page migration have a lot in
> common.
>
> This session is to collect cases that are known to be problematic, and
> to start discussing possible approaches to make some of these
> un-migratable allocations migratable, or alternative strategies to deal
> with this.
>
>
> [1] https://lkml.kernel.org/r/20250129115411.2077152-1-david@redhat.com
> [2]
> https://lkml.kernel.org/r/CAJnrk1ZCgff6ZWmqKzBXFq5uAEbms46OexA1axWS5v-PCZFqJg@mail.gmail.com
> [3]
> https://lkml.kernel.org/r/4febc035-a4ff-4afe-a9a0-d127826852a9@redhat.com
>
> --
> Cheers,
>
> David / dhildenb
>
>

We have run in to the same issues (especially the writeback one), so a
definite +1 on this topic from me.

- Frank

Re: [LSF/MM/BPF TOPIC] Migrating the un-migratable

[Shakeel Butt]

On Thu, Jan 30, 2025 at 11:39:29AM -0800, Frank van der Linden wrote:
> On Wed, Jan 29, 2025 at 8:10 AM David Hildenbrand <david@redhat.com> wrote:
> >
> > Hi,
> >
> > ___GFP_MOVABLE allocations are supposed to be movable -> migratable: the
> > page allocator can place them on
> > MIGRATE_CMA/ZONE_MOVABLE/MIGRATE_MOVABLE areas: areas where the
> > expectation is that allocations can be migrated (somewhat reliably) to
> > different memory areas on demand.
> >
> > Mechanisms that turn such allocations unmigratable, such as long-term
> > page pinning (FOLL_LONGTERM), migrate these allocations at least out of
> > MIGRATE_CMA/ZONE_MOVABLE areas first.
> >
> > Ideally, we'd only perform this migration if really required (e.g.,
> > long-term pinning), and rather "fix" other cases to not turn allocations
> > unmigratable.
> >
> > However, we have some rather obscure cases that can turn migratable
> > allocations effectively unmigratable for a long/indeterminate time,
> > possibly controlled by unprivileged user space.
> >
> > Possible effects include:
> > * CMA allocations failing
> > * Memory hotunplug not making progress
> > * Memory compaction not working as expected
> >
> > Some cases I can fix myself [1], others are harder to tackle.
> >
> > As one example, in context of FUSE we recently discovered that folios
> > that are under writeback cannot be migrated, and user space in control
> > of when writeback will end. Something similar can happen ->readahead()
> > where user space is in charge of supplying page content. Networking
> > filesystems in general seem to be prone to this as well.
> >
> > As another example, failing to split large folios can prevent migration
> > if memory is fragmented. XFS (IOMAP in general) refuses to split folios
> > that are dirty [3]. Splitting of folios and page migration have a lot in
> > common.
> >
> > This session is to collect cases that are known to be problematic, and
> > to start discussing possible approaches to make some of these
> > un-migratable allocations migratable, or alternative strategies to deal
> > with this.
> >
> >
> > [1] https://lkml.kernel.org/r/20250129115411.2077152-1-david@redhat.com
> > [2]
> > https://lkml.kernel.org/r/CAJnrk1ZCgff6ZWmqKzBXFq5uAEbms46OexA1axWS5v-PCZFqJg@mail.gmail.com
> > [3]
> > https://lkml.kernel.org/r/4febc035-a4ff-4afe-a9a0-d127826852a9@redhat.com
> >
> > --
> > Cheers,
> >
> > David / dhildenb
> >
> >
> 
> We have run in to the same issues (especially the writeback one), so a
> definite +1 on this topic from me.

Can you share a bit more on what issues you ran into with writeback
folios causing fragmentation or making memory unmovable for arbitrarily
long time? 

Re: [LSF/MM/BPF TOPIC] Migrating the un-migratable

[Matthew Wilcox]

On Wed, Jan 29, 2025 at 05:10:03PM +0100, David Hildenbrand wrote:
> As one example, in context of FUSE we recently discovered that folios that
> are under writeback cannot be migrated, and user space in control of when
> writeback will end. Something similar can happen ->readahead() where user
> space is in charge of supplying page content. Networking filesystems in
> general seem to be prone to this as well.

You're not wrong.  The question is whether we're willing to put the
asterisk on "In the presence of a misbehaving server (network or fuse),
our usual guarantees do not apply".  I'm not sure it's a soluble
problem, though.  Normally writeback (or, as you observed, readahead)
completes just fine and we don't need to use non-movable pages for them.

But if someone trips over the network cable, anything in flight becomes
unmovable until someone plugs it back in.  We've given the DMA address
of the memory to a network adapter, and that's generally a non-revokable
step (maybe the iommu could save us, but at what cost?)

> As another example, failing to split large folios can prevent migration if
> memory is fragmented. XFS (IOMAP in general) refuses to split folios that
> are dirty [3]. Splitting of folios and page migration have a lot in common.

Welll ... yes and no.  iomap refuses to split a dirty folio because it
has a per-folio data structure which tells us which blocks in the folio
are dirty.  If we split the folio, we have to allocate an extra data
structure for each new folio that we create.  It's not impossible, but
it's a big ask for slab.  It'll be a lot better once Zi Yan's patch is
in to only split folios as needed rather than all the way.

That problem doesn't arise for migration.  filemap_release_folio() is
only called by fallback_migrate_folio(), which is only called if the
filesystem doesn't provide a ->migrate_folio callback.  All iomap
users should use filemap_migrate_folio() which just has to move the
data structure from the old folio to the new.

Re: [LSF/MM/BPF TOPIC] Migrating the un-migratable

[Shakeel Butt]

On Thu, Jan 30, 2025 at 09:48:42PM +0000, Matthew Wilcox wrote:
> On Wed, Jan 29, 2025 at 05:10:03PM +0100, David Hildenbrand wrote:
> > As one example, in context of FUSE we recently discovered that folios that
> > are under writeback cannot be migrated, and user space in control of when
> > writeback will end. Something similar can happen ->readahead() where user
> > space is in charge of supplying page content. Networking filesystems in
> > general seem to be prone to this as well.
> 
> You're not wrong.  The question is whether we're willing to put the
> asterisk on "In the presence of a misbehaving server (network or fuse),
> our usual guarantees do not apply".  I'm not sure it's a soluble
> problem, though.  Normally writeback (or, as you observed, readahead)
> completes just fine and we don't need to use non-movable pages for them.
> 
> But if someone trips over the network cable, anything in flight becomes
> unmovable until someone plugs it back in.  We've given the DMA address
> of the memory to a network adapter, and that's generally a non-revokable
> step (maybe the iommu could save us, but at what cost?)
> 

My position is more aligned with Willy's. We definitely should discuss
if we can solve the general problem of (im)movability due to writeback
or readahead but I think targeting precise problem will be more
fruitful. Untrusted fuse server deliberatly causing immovable memory is
a real problem as anyone can run fuse server and mount fuse without any
permissions. At least to me a misbehaving but trusted server is less of
an (practical) issue. (Please correct me if I miss something like this
is also a real issue in multi-tenancy world).

Joanne has some ideas [1] on fuse specific solution but having a
discussion on general solution would be beneficial as well.

[1] https://lore.kernel.org/all/CAJnrk1ZCgff6ZWmqKzBXFq5uAEbms46OexA1axWS5v-PCZFqJg@mail.gmail.com/

Re: [LSF/MM/BPF TOPIC] Migrating the un-migratable

[David Hildenbrand]

On 30.01.25 22:48, Matthew Wilcox wrote:
> On Wed, Jan 29, 2025 at 05:10:03PM +0100, David Hildenbrand wrote:
>> As one example, in context of FUSE we recently discovered that folios that
>> are under writeback cannot be migrated, and user space in control of when
>> writeback will end. Something similar can happen ->readahead() where user
>> space is in charge of supplying page content. Networking filesystems in
>> general seem to be prone to this as well.
> 
> You're not wrong.  The question is whether we're willing to put the
> asterisk on "In the presence of a misbehaving server (network or fuse),
> our usual guarantees do not apply".  I'm not sure it's a soluble
> problem, though.  Normally writeback (or, as you observed, readahead)
> completes just fine and we don't need to use non-movable pages for them.

Yes, we discussed a lot of that, and where it could be handled, and 
where it simply cannot be handled. I also don't believe that we can -- 
or even should try to -- be perfect.

There are certainly cases that simply cannot be handled, or only very 
very painfully. Always falling back to allocating from use non-movable 
memory "simply because it could happen" (e.g., someone could trip over 
the network cable) is stupid.

I think it's all a matter of seeing how far we can get with reasonable 
effort, and which cases are really problematic -- e.g., untrusted fuse 
-- and how they could be better handled.

The discussion so far already revealed a bunch of interesting 
approaches, but also limitations (e.g., fuse with splice).

> 
> But if someone trips over the network cable, anything in flight becomes
> unmovable until someone plugs it back in.  We've given the DMA address
> of the memory to a network adapter, and that's generally a non-revokable
> step (maybe the iommu could save us, but at what cost?)

Right, and as we discussed as part of the FUSE discussion.

It will be very interesting to hear into which problems others (e.g., 
Frank) ran into and how they could be mitigated/solved.

> 
>> As another example, failing to split large folios can prevent migration if
>> memory is fragmented. XFS (IOMAP in general) refuses to split folios that
>> are dirty [3]. Splitting of folios and page migration have a lot in common.
> 
> Welll ... yes and no.  iomap refuses to split a dirty folio because it
> has a per-folio data structure which tells us which blocks in the folio
> are dirty.  If we split the folio, we have to allocate an extra data
> structure for each new folio that we create.  It's not impossible, but
> it's a big ask for slab.  It'll be a lot better once Zi Yan's patch is
> in to only split folios as needed rather than all the way.
> 
> That problem doesn't arise for migration.  filemap_release_folio() is
> only called by fallback_migrate_folio(), which is only called if the
> filesystem doesn't provide a ->migrate_folio callback.  All iomap
> users should use filemap_migrate_folio() which just has to move the
> data structure from the old folio to the new.

Right, that's why I said: "if memory is fragmented".

Try migrating a 512 MiB folio (arm64 64k ..) when you cannot split 
(dirty) and memory is all fragmented such that you cannot easily grab a 
free 512 MiB one. Of course, that's an extreme example, but it can also 
easily happen on systems with smaller folios ...

... and then, we now have folios that cannot be split below a certain 
min order ... (well, we kind-of had that in an extreme form with hugetlb 
that cannot be slit at all)

-- 
Cheers,

David / dhildenb

Re: [LSF/MM/BPF TOPIC] Migrating the un-migratable

[David Hildenbrand]

On 29.01.25 17:10, David Hildenbrand wrote:
> Hi,
> 
> ___GFP_MOVABLE allocations are supposed to be movable -> migratable: the
> page allocator can place them on
> MIGRATE_CMA/ZONE_MOVABLE/MIGRATE_MOVABLE areas: areas where the
> expectation is that allocations can be migrated (somewhat reliably) to
> different memory areas on demand.
> 
> Mechanisms that turn such allocations unmigratable, such as long-term
> page pinning (FOLL_LONGTERM), migrate these allocations at least out of
> MIGRATE_CMA/ZONE_MOVABLE areas first.
> 
> Ideally, we'd only perform this migration if really required (e.g.,
> long-term pinning), and rather "fix" other cases to not turn allocations
> unmigratable.
> 
> However, we have some rather obscure cases that can turn migratable
> allocations effectively unmigratable for a long/indeterminate time,
> possibly controlled by unprivileged user space.
> 
> Possible effects include:
> * CMA allocations failing
> * Memory hotunplug not making progress
> * Memory compaction not working as expected
> 
> Some cases I can fix myself [1], others are harder to tackle.
> 
> As one example, in context of FUSE we recently discovered that folios
> that are under writeback cannot be migrated, and user space in control
> of when writeback will end. Something similar can happen ->readahead()
> where user space is in charge of supplying page content. Networking
> filesystems in general seem to be prone to this as well.
> 
> As another example, failing to split large folios can prevent migration
> if memory is fragmented. XFS (IOMAP in general) refuses to split folios
> that are dirty [3]. Splitting of folios and page migration have a lot in
> common.
> 
> This session is to collect cases that are known to be problematic, and
> to start discussing possible approaches to make some of these
> un-migratable allocations migratable, or alternative strategies to deal
> with this.
> 
> 
> [1] https://lkml.kernel.org/r/20250129115411.2077152-1-david@redhat.com
> [2]
> https://lkml.kernel.org/r/CAJnrk1ZCgff6ZWmqKzBXFq5uAEbms46OexA1axWS5v-PCZFqJg@mail.gmail.com
> [3]
> https://lkml.kernel.org/r/4febc035-a4ff-4afe-a9a0-d127826852a9@redhat.com
> 

Slides from today:

https://drive.google.com/file/d/1uX80M1x86Oz3DFoHif-JLx1rlC_Nh93R/view?usp=sharing

-- 
Cheers,

David / dhildenb