Re: [PATCH] Revert "mm, hugetlb: remove hugepages_treat_as_movable sysctl"

[David Hildenbrand <david@redhat.com>]

On 09.10.25 23:31, Gregory Price wrote:
> On Thu, Oct 09, 2025 at 08:51:54PM +0200, David Hildenbrand wrote:
>> On 09.10.25 17:29, Gregory Price wrote:
>> Or would it be sufficient to selectively enable (explicit opt-in) some user
>> pages to end up on ZONE_MOVABLE? IOW, change the semantics of the zone by an
>> admin.
>>
>> Like, allowing longterm pinning on ZONE_MOVABLE.
>>
>> Sure, it would degrade memory hotunplug (until the relevant applications are
>> shut down) and probably some other things.
>>
>> Further, I am not so sure about the value of having ZONE_MOVABLE sprinkled
>> with small unmovable allocations (same concern regarding any such zone that
>> allows for unmovable things). Kind of against the whole concept.
>>
>> But I mean, if the admin decides to do that (opt in), so he is to blame.
>>
> 
> For what it's worth, this patch (or the new one i posted as an RFC), I
> was able to allocate gigantic pages and migrate them back and forth
> between nodes even after they were allocated for KVM instances.
> 
> I was surprised this did not cause pinning.

KVM does not end up longterm-pinning pages (what we care about regarding 
migration) when mapping stuff into the guest MMU, so KVM in general is 
not a problem.

The problem shows up once you would try to use something like vfio, 
liburing fixed buffers etc, where we will longterm-pin pages.

> 
> This was all while running the QEMU machine actively eating ~2GB of
> memory.  So this seems... acceptable?  My primary use case was VM
> hugepages, but it doesn't even seem like these have been pinned.
> 
> I think the confidential-compute / guest_memfd path would have an
> issue, because those are pinned and/or entirely unmapped from the
> host, but that just seems like a known quantity and a reason to leave
> this off by default (make them read the docs :]).

guest_memfd allocates folios without GFP_MOVABLE, because they are ... 
unmovable. So they would never end up on ZONE_MOVABLE.

There are prototypes / ideas to support migration of guest_memfd pages, 
so it would be solvable. At least for some scenarios.

> 
> Seems like this is pretty stable tbh.  Obviously if you hack off the
> node0 hugepages migration fails - but I feel like you're signing up for
> that when you turn the bit on.

Right, just needs to be documented thoroughly IMHO.

-- 
Cheers

David / dhildenb