>> 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
