All of lore.kernel.org
 help / color / mirror / Atom feed
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


      reply	other threads:[~2026-07-22  9:58 UTC|newest]

Thread overview: 28+ 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 13:13   ` sashiko-bot
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 13:14   ` sashiko-bot
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:13   ` sashiko-bot
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.