On Wed, Jul 5, 2023 at 2:28 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Wed, Jul 05, 2023 at 04:25:21PM -0400, Peter Xu wrote: > > There'll still try to be a final fix, am I right? As IIRC allowing page > > faults during fork() is one of the major goals of vma lock. > > Good grief, no. Why would we want to optimise something that happens > so rarely? The goal is, as usual, more performance. Satisfying page > faults while mmap()/munmap()/mprotect() are happening is worthwhile. > Those happen a lot more than fork(). > > In this case though, there's also a priority-inversion problem that > we're trying to solve where process A (high priority) calls mmap() while > process B (low priority) is reading /proc/$pid/smaps and now (because > rwsems are fair), none of process A's other threads can satisy any page > faults until process B is scheduled. > > Where on earth did you get the idea that we cared even a little bit > about the performance of page fault during fork()? I think the original reasoning for Android to improve app launch time could have made that impression. However the speed up there comes not from allowing page faults into the parent process (Zygote) while it forks a child but rather from the child being able to fault pages and establish its mappings concurrently.
