linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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 ... ]---


  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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox