From: Wandun <chenwandun1@gmail.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
"David Hildenbrand (Arm)" <david@kernel.org>
Cc: vbabka@kernel.org, rostedt@goodmis.org, mhiramat@kernel.org,
Alexander.Krabler@kuka.com, hughd@google.com, fvdl@google.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
linux-rt-devel@lists.linux.dev, akpm@linux-foundation.org,
surenb@google.com, mhocko@suse.com, jackmanb@google.com,
hannes@cmpxchg.org, ziy@nvidia.com, ljs@kernel.org,
riel@surriel.com, liam@infradead.org, harry@kernel.org,
jannh@google.com, lance.yang@linux.dev,
mathieu.desnoyers@efficios.com, matthew.brost@intel.com,
joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com,
gourry@gourry.net, ying.huang@linux.alibaba.com,
apopple@nvidia.com, pfalcato@suse.de
Subject: Re: [PATCH v2 4/4] mm/mlock: migrate folios out of CMA when mlocking a range
Date: Wed, 22 Jul 2026 17:58:00 +0800 [thread overview]
Message-ID: <2e9902e7-3f40-49d5-afb0-e710fb01ab39@gmail.com> (raw)
In-Reply-To: <20260709131509.iIPP2VBh@linutronix.de>
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 <chenwandun@lixiang.com>
>>>
>>> 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
prev parent reply other threads:[~2026-07-22 9:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 12:59 [PATCH v2 0/4] mm: honour compact_unevictable_allowed in mlock and CMA paths Wandun Chen
2026-07-07 12:59 ` [PATCH v2 1/4] mm/migrate: do not migrate folios mapped into VM_LOCKED VMAs under compaction Wandun Chen
2026-07-07 13:44 ` Lorenzo Stoakes
2026-07-07 13:55 ` Lorenzo Stoakes
2026-07-09 8:25 ` Wandun
2026-07-09 15:00 ` Lorenzo Stoakes
2026-07-14 1:45 ` Wandun
2026-07-09 3:31 ` Wandun
2026-07-09 16:10 ` Zi Yan
2026-07-14 6:28 ` Wandun
2026-07-07 12:59 ` [PATCH v2 2/4] mm/mlock: wait for migration to finish when mlocking a folio Wandun Chen
2026-07-07 14:33 ` Lorenzo Stoakes
2026-07-09 8:42 ` Sebastian Andrzej Siewior
2026-07-09 11:50 ` Wandun
2026-07-07 12:59 ` [PATCH v2 3/4] mm/migrate: add tracepoint for folios unmapped during migration Wandun Chen
2026-07-07 12:59 ` [PATCH v2 4/4] mm/mlock: migrate folios out of CMA when mlocking a range Wandun Chen
2026-07-07 13:36 ` Wandun
2026-07-07 14:57 ` Lorenzo Stoakes
2026-07-07 14:54 ` Lorenzo Stoakes
2026-07-09 9:13 ` Sebastian Andrzej Siewior
2026-07-09 12:25 ` Wandun
2026-07-13 10:01 ` Wandun
2026-07-09 10:04 ` David Hildenbrand (Arm)
2026-07-09 13:15 ` Sebastian Andrzej Siewior
2026-07-22 9:58 ` Wandun [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2e9902e7-3f40-49d5-afb0-e710fb01ab39@gmail.com \
--to=chenwandun1@gmail.com \
--cc=Alexander.Krabler@kuka.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=bigeasy@linutronix.de \
--cc=byungchul@sk.com \
--cc=david@kernel.org \
--cc=fvdl@google.com \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=harry@kernel.org \
--cc=hughd@google.com \
--cc=jackmanb@google.com \
--cc=jannh@google.com \
--cc=joshua.hahnjy@gmail.com \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=matthew.brost@intel.com \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=pfalcato@suse.de \
--cc=rakie.kim@sk.com \
--cc=riel@surriel.com \
--cc=rostedt@goodmis.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox