From: Wentao Guan <guanwentao@uniontech.com>
To: chenhuacai@kernel.org
Cc: kernel@xen0n.name, linux-kernel@vger.kernel.org,
loongarch@lists.linux.dev, zhanjun@uniontech.com,
niecheng1@uniontech.com, Wentao Guan <guanwentao@uniontech.com>
Subject: [PATCH] LoongArch: mm: try VMA lock-based page fault handling first
Date: Thu, 25 Sep 2025 17:29:02 +0800 [thread overview]
Message-ID: <20250925092902.1366058-1-guanwentao@uniontech.com> (raw)
Attempt VMA lock-based page fault handling first, and fall back to the
existing mmap_lock-based handling if that fails.
The "ebizzy -mTRp" on 3A6000 shows that PER_VMA_LOCK can
improve the benchmark by about 20.7%.
This is the loongarch variant of "x86/mm: try VMA lock-based page fault
handling first".
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
---
ebizzy-0.3(can download by phoronix-test-suite):
before patch:
97800 records/s
real 10.00 s user 0.25 s sys 13.54 s
97835 records/s
real 10.00 s user 0.27 s sys 13.51 s
97929 records/s
real 10.00 s user 0.26 s sys 13.53 s
97736 records/s
real 10.00 s user 0.31 s sys 13.48 s
97914 records/s
real 10.00 s user 0.30 s sys 13.50 s
97916 records/s
real 10.00 s user 0.31 s sys 13.48 s
97857 records/s
real 10.00 s user 0.28 s sys 13.51 s
97927 records/s
real 10.00 s user 0.24 s sys 13.55 s
97962 records/s
real 10.00 s user 0.41 s sys 13.39 s
97501 records/s
real 10.00 s user 0.20 s sys 13.53 s
after patch:
117645 records/s
real 10.00 s user 0.31 s sys 23.17 s
118207 records/s
real 10.00 s user 0.37 s sys 23.18 s
118426 records/s
real 10.00 s user 0.32 s sys 23.14 s
118172 records/s
real 10.00 s user 0.44 s sys 23.07 s
118548 records/s
real 10.00 s user 0.45 s sys 23.04 s
118011 records/s
real 10.00 s user 0.32 s sys 23.15 s
118143 records/s
real 10.00 s user 0.41 s sys 23.09 s
118181 records/s
real 10.00 s user 0.42 s sys 23.12 s
117721 records/s
real 10.00 s user 0.34 s sys 23.17 s
118138 records/s
real 10.00 s user 0.42 s sys 23.04 s
---
---
arch/loongarch/Kconfig | 1 +
arch/loongarch/mm/fault.c | 49 +++++++++++++++++++++++++++++++++++++++
2 files changed, 50 insertions(+)
diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
index 0631a6b11281b..1c517954157c0 100644
--- a/arch/loongarch/Kconfig
+++ b/arch/loongarch/Kconfig
@@ -69,6 +69,7 @@ config LOONGARCH
select ARCH_SUPPORTS_LTO_CLANG_THIN
select ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS
select ARCH_SUPPORTS_NUMA_BALANCING
+ select ARCH_SUPPORTS_PER_VMA_LOCK
select ARCH_SUPPORTS_RT
select ARCH_USE_BUILTIN_BSWAP
select ARCH_USE_CMPXCHG_LOCKREF
diff --git a/arch/loongarch/mm/fault.c b/arch/loongarch/mm/fault.c
index deefd9617d008..d2dc3e194dd76 100644
--- a/arch/loongarch/mm/fault.c
+++ b/arch/loongarch/mm/fault.c
@@ -215,6 +215,53 @@ static void __kprobes __do_page_fault(struct pt_regs *regs,
flags |= FAULT_FLAG_USER;
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
+ if (!(flags & FAULT_FLAG_USER))
+ goto lock_mmap;
+
+ vma = lock_vma_under_rcu(mm, address);
+ if (!vma)
+ goto lock_mmap;
+
+ if (write) {
+ flags |= FAULT_FLAG_WRITE;
+ if (!(vma->vm_flags & VM_WRITE)) {
+ vma_end_read(vma);
+ si_code = SEGV_ACCERR;
+ goto bad_area_nosemaphore;
+ }
+ } else {
+ if (!(vma->vm_flags & VM_EXEC) && address == exception_era(regs)){
+ vma_end_read(vma);
+ si_code = SEGV_ACCERR;
+ goto bad_area_nosemaphore;
+ }
+ if (!(vma->vm_flags & (VM_READ | VM_WRITE)) && address != exception_era(regs)){
+ vma_end_read(vma);
+ si_code = SEGV_ACCERR;
+ goto bad_area_nosemaphore;
+ }
+ }
+
+ fault = handle_mm_fault(vma, address, flags | FAULT_FLAG_VMA_LOCK, regs);
+ if (!(fault & (VM_FAULT_RETRY | VM_FAULT_COMPLETED)))
+ vma_end_read(vma);
+
+ if (!(fault & VM_FAULT_RETRY)) {
+ count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
+ goto done;
+ }
+ count_vm_vma_lock_event(VMA_LOCK_RETRY);
+ if (fault & VM_FAULT_MAJOR)
+ flags |= FAULT_FLAG_TRIED;
+
+ /* Quick path to respond to signals */
+ if (fault_signal_pending(fault, regs)) {
+ if (!user_mode(regs))
+ no_context(regs, write, address);
+ return;
+ }
+lock_mmap:
+
retry:
vma = lock_mm_and_find_vma(mm, address, regs);
if (unlikely(!vma))
@@ -292,6 +339,8 @@ static void __kprobes __do_page_fault(struct pt_regs *regs,
}
mmap_read_unlock(mm);
+done:
+ return;
}
asmlinkage void __kprobes do_page_fault(struct pt_regs *regs,
--
2.20.1
next reply other threads:[~2025-09-25 9:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-25 9:29 Wentao Guan [this message]
2025-09-28 13:58 ` Huacai Chen
2025-09-28 14:46 ` Wentao Guan
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=20250925092902.1366058-1-guanwentao@uniontech.com \
--to=guanwentao@uniontech.com \
--cc=chenhuacai@kernel.org \
--cc=kernel@xen0n.name \
--cc=linux-kernel@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=niecheng1@uniontech.com \
--cc=zhanjun@uniontech.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
all inboxes | Powered by JetHome®