On Wed, Jul 05, 2023 at 10:27:56PM +0100, Matthew Wilcox 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. Is it possible to extend vma lock to things like smaps? > > Where on earth did you get the idea that we cared even a little bit > about the performance of page fault during fork()? My memory, when I was talking to someone during the conference that mentioned such a use case. But my memory can be just wrong, in that case it's my fault, but I hope it's still fine to just ask here. -- Peter Xu
