From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Lokesh Gidra <lokeshgidra@google.com>
Cc: akpm@linux-foundation.org, aarcange@redhat.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
21cnbao@gmail.com, ngeoffray@google.com,
Suren Baghdasaryan <surenb@google.com>,
Kalesh Singh <kaleshsingh@google.com>,
Barry Song <v-songbaohua@oppo.com>,
David Hildenbrand <david@redhat.com>,
Peter Xu <peterx@redhat.com>
Subject: Re: [PATCH v2] userfaultfd: opportunistic TLB-flush batching for present pages in MOVE
Date: Wed, 6 Aug 2025 18:18:48 +0100 [thread overview]
Message-ID: <a00a8cca-e435-434f-855c-a3b56f2aece4@lucifer.local> (raw)
In-Reply-To: <20250805121410.1658418-1-lokeshgidra@google.com>
Andrew - Could we drop this for now, please, it's splatting and has broken
mm-new.
Lokesh - could you make sure to run the mm self tests with CONFIG_DBUG_VM
set before you submit please? As this is splat is occurring immediately on
uffd-unit-tests.
On Tue, Aug 05, 2025 at 05:14:10AM -0700, Lokesh Gidra wrote:
> MOVE ioctl's runtime is dominated by TLB-flush cost, which is required
> for moving present pages. Mitigate this cost by opportunistically
> batching present contiguous pages for TLB flushing.
>
> Without batching, in our testing on an arm64 Android device with UFFD GC,
> which uses MOVE ioctl for compaction, we observed that out of the total
> time spent in move_pages_pte(), over 40% is in ptep_clear_flush(), and
> ~20% in vm_normal_folio().
>
> With batching, the proportion of vm_normal_folio() increases to over
> 70% of move_pages_pte() without any changes to vm_normal_folio().
> Furthermore, time spent within move_pages_pte() is only ~20%, which
> includes TLB-flush overhead.
>
> Cc: Suren Baghdasaryan <surenb@google.com>
> Cc: Kalesh Singh <kaleshsingh@google.com>
> Cc: Barry Song <v-songbaohua@oppo.com>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Peter Xu <peterx@redhat.com>
> Signed-off-by: Lokesh Gidra <lokeshgidra@google.com>
> ---
> Changes since v1 [1]
> - Removed flush_tlb_batched_pending(), per Barry Song
> - Unified single and multi page case, per Barry Song
Splat, decoded via scripts/decode_stacktrace.sh:
$ sudo ./uffd-unit-tests
Testing UFFDIO_API (with syscall)... done
Testing UFFDIO_API (with /dev/userfaultfd)... done
Testing register-ioctls on anon... done
Testing register-ioctls on shmem... done
Testing register-ioctls on shmem-private... done
Testing register-ioctls on hugetlb... skipped [reason: memory allocation failed]
Testing register-ioctls on hugetlb-private... skipped [reason: memory allocation failed]
Testing zeropage on anon... done
Testing zeropage on shmem... done
Testing zeropage on shmem-private... done
Testing zeropage on hugetlb... skipped [reason: memory allocation failed]
Testing zeropage on hugetlb-private... skipped [reason: memory allocation failed]
Testing move on anon... [ 12.230740] Kernel panic - not syncing: kernel: panic_on_warn set ...
[ 12.231322] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-1-1 04/01/2014
[ 12.231655] Call Trace:
[ 12.231748] <TASK>
[ 12.231830] dump_stack_lvl (lib/dump_stack.c:122)
[ 12.231963] vpanic (kernel/panic.c:448)
[ 12.232088] panic (kernel/panic.c:312 kernel/panic.c:303)
[ 12.232199] ? move_pages (mm/userfaultfd.c:1964 (discriminator 2))
Appears to be:
VM_WARN_ON_ONCE(err > 0);
[ 12.232341] check_panic_on_warn.cold (kernel/panic.c:327)
[ 12.232502] __warn.cold (kernel/panic.c:839)
[ 12.232628] ? move_pages (mm/userfaultfd.c:1964 (discriminator 2))
[ 12.232764] report_bug (lib/bug.c:176 lib/bug.c:215)
[ 12.232891] handle_bug (arch/x86/kernel/traps.c:338 (discriminator 1))
[ 12.233034] ? move_pages (mm/userfaultfd.c:1964 (discriminator 2))
[ 12.233174] exc_invalid_op (arch/x86/kernel/traps.c:392 (discriminator 3))
[ 12.233312] asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)
[ 12.233460] RIP: 0010:move_pages (mm/userfaultfd.c:1964 (discriminator 2))
[ 12.233615] Code: 5e 41 5f c3 cc cc cc cc 49 89 c5 e9 e1 fe ff ff eb c4 e9 6d ff ff ff 90 0f 0b 90 45 31 ff eb cf 90 0f 0b 90 48 85 d2 7e c6 90 <0f> 0b 90 eb b9 90 0f 0b 90 f7 c1 ff 0f 00 00 0f 84 4e fe ff ff 90
All code
========
0: 5e pop %rsi
1: 41 5f pop %r15
3: c3 ret
4: cc int3
5: cc int3
6: cc int3
7: cc int3
8: 49 89 c5 mov %rax,%r13
b: e9 e1 fe ff ff jmp 0xfffffffffffffef1
10: eb c4 jmp 0xffffffffffffffd6
12: e9 6d ff ff ff jmp 0xffffffffffffff84
17: 90 nop
18: 0f 0b ud2
1a: 90 nop
1b: 45 31 ff xor %r15d,%r15d
1e: eb cf jmp 0xffffffffffffffef
20: 90 nop
21: 0f 0b ud2
23: 90 nop
24: 48 85 d2 test %rdx,%rdx
27: 7e c6 jle 0xffffffffffffffef
29: 90 nop
2a:* 0f 0b ud2 <-- trapping instruction
2c: 90 nop
2d: eb b9 jmp 0xffffffffffffffe8
2f: 90 nop
30: 0f 0b ud2
32: 90 nop
33: f7 c1 ff 0f 00 00 test $0xfff,%ecx
39: 0f 84 4e fe ff ff je 0xfffffffffffffe8d
3f: 90 nop
Code starting with the faulting instruction
===========================================
0: 0f 0b ud2
2: 90 nop
3: eb b9 jmp 0xffffffffffffffbe
5: 90 nop
6: 0f 0b ud2
8: 90 nop
9: f7 c1 ff 0f 00 00 test $0xfff,%ecx
f: 0f 84 4e fe ff ff je 0xfffffffffffffe63
15: 90 nop
[ 12.234294] RSP: 0018:ffffafeb00483d70 EFLAGS: 00010206
[ 12.234484] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000002
[ 12.234738] RDX: 0000000000001000 RSI: ffff90afbb433078 RDI: ffff90afbc7f0080
[ 12.234997] RBP: ffff90afbc7f0000 R08: ffff90b037cae540 R09: 0000000000000001
[ 12.235255] R10: ffffffffffffffff R11: 0000000000000003 R12: ffff90af01acb980
[ 12.235508] R13: ffff90afbc7f0240 R14: ffffefc386e80b00 R15: 0000000000001000
[ 12.235764] userfaultfd_ioctl (fs/userfaultfd.c:1925 fs/userfaultfd.c:2046)
[ 12.235917] __x64_sys_ioctl (fs/ioctl.c:51 fs/ioctl.c:598 fs/ioctl.c:584 fs/ioctl.c:584)
[ 12.236065] ? ksys_read (./include/linux/file.h:63 ./include/linux/file.h:80 ./include/linux/file.h:85 fs/read_write.c:706)
[ 12.236202] do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))
[ 12.236345] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
[ 12.236524] RIP: 0033:0x7f457600fecd
[ 12.236658] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
All code
========
0: 04 25 add $0x25,%al
2: 28 00 sub %al,(%rax)
4: 00 00 add %al,(%rax)
6: 48 89 45 c8 mov %rax,-0x38(%rbp)
a: 31 c0 xor %eax,%eax
c: 48 8d 45 10 lea 0x10(%rbp),%rax
10: c7 45 b0 10 00 00 00 movl $0x10,-0x50(%rbp)
17: 48 89 45 b8 mov %rax,-0x48(%rbp)
1b: 48 8d 45 d0 lea -0x30(%rbp),%rax
1f: 48 89 45 c0 mov %rax,-0x40(%rbp)
23: b8 10 00 00 00 mov $0x10,%eax
28: 0f 05 syscall
2a:* 89 c2 mov %eax,%edx <-- trapping instruction
2c: 3d 00 f0 ff ff cmp $0xfffff000,%eax
31: 77 1a ja 0x4d
33: 48 8b 45 c8 mov -0x38(%rbp),%rax
37: 64 48 2b 04 25 28 00 sub %fs:0x28,%rax
3e: 00 00
Code starting with the faulting instruction
===========================================
0: 89 c2 mov %eax,%edx
2: 3d 00 f0 ff ff cmp $0xfffff000,%eax
7: 77 1a ja 0x23
9: 48 8b 45 c8 mov -0x38(%rbp),%rax
d: 64 48 2b 04 25 28 00 sub %fs:0x28,%rax
14: 00 00
[ 12.237333] RSP: 002b:00007f4569dfed20 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 12.237599] RAX: ffffffffffffffda RBX: 0000000000001000 RCX: 00007f457600fecd
[ 12.237854] RDX: 00007f4569dfeda0 RSI: 00000000c028aa05 RDI: 0000000000000009
[ 12.238129] RBP: 00007f4569dfed70 R08: 0000000000000000 R09: 0000000000000000
[ 12.238384] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffb974ba60
[ 12.238636] R13: 00007fffb974b830 R14: 00007f4569dffcdc R15: 00007fffb974b937
[ 12.238890] </TASK>
[ 12.239094] Kernel Offset: 0x33000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 12.239480] ---[ end Kernel panic - not syncing: kernel: panic_on_warn set ... ]---
next prev parent reply other threads:[~2025-08-06 17:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-05 12:14 [PATCH v2] userfaultfd: opportunistic TLB-flush batching for present pages in MOVE Lokesh Gidra
2025-08-06 17:18 ` Lorenzo Stoakes [this message]
2025-08-06 17:30 ` Lokesh Gidra
2025-08-07 10:42 ` Lokesh Gidra
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=a00a8cca-e435-434f-855c-a3b56f2aece4@lucifer.local \
--to=lorenzo.stoakes@oracle.com \
--cc=21cnbao@gmail.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=kaleshsingh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lokeshgidra@google.com \
--cc=ngeoffray@google.com \
--cc=peterx@redhat.com \
--cc=surenb@google.com \
--cc=v-songbaohua@oppo.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.