From: Wandun Chen <chenwandun1@gmail.com>
To: vbabka@kernel.org, david@kernel.org, rostedt@goodmis.org,
mhiramat@kernel.org, Alexander.Krabler@kuka.com,
hughd@google.com, fvdl@google.com, bigeasy@linutronix.de,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
linux-rt-devel@lists.linux.dev
Cc: 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: [PATCH v2 2/4] mm/mlock: wait for migration to finish when mlocking a folio
Date: Tue, 7 Jul 2026 20:59:23 +0800 [thread overview]
Message-ID: <20260707125925.3725177-3-chenwandun1@gmail.com> (raw)
In-Reply-To: <20260707125925.3725177-1-chenwandun1@gmail.com>
From: Wandun Chen <chenwandun@lixiang.com>
In RT kernels, sysctl_compact_unevictable_allowed is false by default,
when the mlock/mlockall system call try to lock all the present page,
the mlock_pte_range function skips non-present entries. If these
non-present entries are migration entries, and the migration is not
guaranteed to have completed before the mlock/mlockall, it may result
in a page fault on subsequent access, which then waits for the
migration to finish, causing spike latency in RT kernels.
Fix it by waiting for the migration to complete during the mlock/mlockall
syscall when sysctl_compact_unevictable_allowed is false.
Fixes: 90d07210ab55 ("mm: mlock: use folios and a folio batch internally")
Suggested-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Wandun Chen <chenwandun@lixiang.com>
Link: https://lore.kernel.org/lkml/c8793c0f-7156-4cb7-9e6e-7909397e2fff@kernel.org/#t
---
mm/mlock.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/mm/mlock.c b/mm/mlock.c
index 97e49038d8d3..ac65de40b22b 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -25,6 +25,7 @@
#include <linux/memcontrol.h>
#include <linux/mm_inline.h>
#include <linux/secretmem.h>
+#include <linux/compaction.h>
#include "internal.h"
@@ -361,8 +362,17 @@ static int mlock_pte_range(pmd_t *pmd, unsigned long addr,
ptl = pmd_trans_huge_lock(pmd, vma);
if (ptl) {
- if (!pmd_present(*pmd))
+ if (!pmd_present(*pmd)) {
+ if (unlikely((vma->vm_flags & VM_LOCKED) &&
+ !compaction_allow_unevictable() &&
+ softleaf_is_migration(softleaf_from_pmd(*pmd)))) {
+ spin_unlock(ptl);
+ pmd_migration_entry_wait(vma->vm_mm, pmd);
+ walk->action = ACTION_AGAIN;
+ return 0;
+ }
goto out;
+ }
if (is_huge_zero_pmd(*pmd))
goto out;
folio = pmd_folio(*pmd);
@@ -383,8 +393,17 @@ static int mlock_pte_range(pmd_t *pmd, unsigned long addr,
for (pte = start_pte; addr != end; pte++, addr += PAGE_SIZE) {
ptent = ptep_get(pte);
- if (!pte_present(ptent))
+ if (!pte_present(ptent)) {
+ if (unlikely((vma->vm_flags & VM_LOCKED) &&
+ !compaction_allow_unevictable() &&
+ softleaf_is_migration(softleaf_from_pte(ptent)))) {
+ pte_unmap_unlock(start_pte, ptl);
+ migration_entry_wait(vma->vm_mm, pmd, addr);
+ walk->action = ACTION_AGAIN;
+ return 0;
+ }
continue;
+ }
folio = vm_normal_folio(vma, addr, ptent);
if (!folio || folio_is_zone_device(folio))
continue;
--
2.43.0
next prev parent reply other threads:[~2026-07-07 13:00 UTC|newest]
Thread overview: 8+ 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-07 12:59 ` Wandun Chen [this message]
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
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=20260707125925.3725177-3-chenwandun1@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