Re: [PATCH v3 2/2] mm: disable CONFIG_PER_VMA_LOCK until its fixed

[Peter Xu <peterx@redhat.com>]

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