Re: [RFC PATCH 0/2] mm/memory_hotplug: bound offline retry loops with a configurable limit

>> Usually that happens when we race offlining (has_unmovable_pages()) with page
>> allocation, and failing on unmovable pages is actually perfectly fine.
>>
>> But for ZONE_MOVABLE we should keep retrying, because some pages might only look
>> temporarily unmovable.
>>
>> So that would be the low hanging fruit: on !ZONE_MOVABLE, fail faster.
> 
> This handles scenarios like Case 1. A page can still be allocated from the range after
> isolation and become slab. When test_pages_isolated() fails, we can re-check that
> page with page_is_unmovable() and return -EBUSY if it's unmovable. I'm currently testing this approach
> will send a patch for review.

Yes, and that we should handle. It's a known race and we should just fail faster
in that case. !ZONE_MOVABLE.

> 
> Case 2 is different. The page is on the LRU, so it is considered movable and the fast-fail condition abovewon't be triggered. Instead page migration keeps failing, causing
> offline_pages() to retry indefinitely
> and can hang forever. This could be handled with a timeout or a user
> policy in the application that
> initiated the hotplug operation (signals). However, for the kworker
> paths that trigger memory
> offlining (ACPI remove, etc.), should this instead be handled by the
> driver rather than relying on
> offline_pages(), similar to virtio-mem?

If it's on ZONE_MOVABLE, then we should figure out why it keeps failing forever
and try fixing that instead.

Above you write: "I can also trigger it in a VM by hot-adding a DIMM, pinning a
page and removing the DIMM."

Anybody who intends to take a longterm pin must be using FOLL_LONGTERM, which
will take care of exactly this condition: migrating memory out of ZONE_MOVABLE
first.

So which interface does you reproducer use to trigger pinning?

-- 
Cheers,

David