Hi Sebastian, David, Sorry for the long delay in getting back to this, and thanks a lot for the review.
On 7/9/26 21:15, Sebastian Andrzej Siewior wrote: > On 2026-07-09 12:04:33 [+0200], David Hildenbrand (Arm) wrote: >> On 7/7/26 14:59, Wandun Chen wrote: >>> From: Wandun Chen <[email protected]> >>> >>> The region covered by mlock[all] may contain CMA pages. cma_alloc installs >> >> What about ZONE_MOVABLE where memory is supposed to be migratable? > > Would it be bad if the pages would not be movable anymore? Does this > effect just memory-hotplug or something else, too? ZONE_MOVABLE does not need the same treatment as CMA. 1. On RT compact_unevictable_allowed is 0 by default, pages in ZONE_MOVABLE are never migrated by compaction, so no latency spike, no problem. 2. For the scenario of memory offlining within ZONE_MOVABLE, because of offline is an explicit administrator action. Any jitter/latency is expected and acceptable, the operator chose to offline memory and would not do so during an RT-critical phase. 3. cma_alloc() runs at runtime, triggered by drivers as part of normal operation, and isolation path hardcodes ISOLATE_UNEVICTABLE, so it migrates the mlocked pages and installs migration entries. The fault-and-wait latency hits the RT task unpredictably during normal operation, which is not expected, and is exactly the spike this patch targets. > >> Also, what about drivers that mmap() CMA memory to user space, and >> __mm_populate()->populate_vma_page_range() would actually try mlocking them, >> and >> they actually must remain on CMA areas? > > It should be safe to skip those. They belong to device and they > shouldn't be affected by anything including getting swapped out. Agreed. Only LRU folios are ever isolated for migration here (isolate_folio_to_list() -> folio_isolate_lru()), and device-owned CMA buffers are not on the LRU, so they are left in place. I'll double-check the mmap paths and make sure this holds, and state it explicitly in v3. Best regards, Wandun > > Sebastian
