Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance

[Hongru Zhang <zhanghongru06@gmail.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2920 bytes --]

> On 5/20/26 23:15, Matthew Wilcox wrote:
> > On Thu, May 21, 2026 at 05:14:20AM +0800, Barry Song wrote:
> >> My understanding is that we should not blame applications here. This is 2026:
> >> there are basically only two kinds of applications — single-threaded and
> >> multi-threaded — and single-threaded applications are nearly extinct.
> > 
> > all of the applications i run are either single threaded or don't fork.
> > what multithreaded applications call fork?
>
> Traditionally the problem was random libraries using fork+execve to launch other
> programs ... instead of using alternatives like posix_spwan (some use cases
> require more work done before execve and cannot yet switch to that). I'd hope
> that that is less of a problem on Android.
>
> I assume Android zygote might be multi threaded? Maybe sshd as well? Systemd?
> But I'd be surprised if there are really performance implications.
>
> Not sure about webbroswers .... I think most of them switched to fork servers,
> where I would assume fork servers would be single-threaded.
>
> So, yeah, getting a clear understanding how this ends up being a problem on
> Android would be great.

Barry asked me to share observations on fork() usage across Android
applications.

I wrote a BPF-based tracing tool (kprobe on copy_process, checking
CLONE_VM to distinguish process creation from thread creation) and ran
it against the top 200 Android applications in the China market during
normal usage scenarios.

Results:
- 82 out of 200 apps (41%) call fork() during normal operation
- Among these, some call fork() from multiple threads

These are not zygote forks — they are fork() calls initiated by app
threads at runtime. Examples by category:

  Browsers:     com.quark.browser, com.UCMobile, com.xunlei.browser
  Shopping:     com.taobao.taobao, com.tmall.wireless, com.achievo.vipshop
  Video:        com.youku.phone, com.qiyi.video, com.hunantv.imgo.activity
  Social/IM:    com.alibaba.android.rimet, com.ss.android.lark
  News:         com.ss.android.article.news, com.ss.android.article.lite
  Navigation:   com.autonavi.minimap, com.sdu.didi.psnger
  Finance:      com.eg.android.AlipayGphone, com.chinamworld.main

This confirms that fork() is widely used in real-world multi-threaded
Android applications. Since dup_mmap() needs to acquire
vma_start_write() for every VMA, holding the VMA lock across I/O
would risk blocking fork() for unpredictable durations in these 82
applications.

Tracing tool (two equivalent implementations):
  bpftrace:         https://gist.github.com/zhr250/bf4384202d598bb4cda71cb9902f15ab
  libbpf-bootstrap: https://gist.github.com/zhr250/76189bdf51bdc8818500e4c8917c6493

Analysis results (top 200 apps):
  https://gist.github.com/zhr250/06f51092c84a49c602a55ac3d186e9ce

Hongru