On Wed, Apr 24, 2019 at 08:01:20PM +0200, Laurent Dufour wrote: > Le 22/04/2019 à 23:29, Michel Lespinasse a écrit : > > Hi Laurent, > > > > Thanks a lot for copying me on this patchset. It took me a few days to > > go through it - I had not been following the previous iterations of > > this series so I had to catch up. I will be sending comments for > > individual commits, but before tat I would like to discuss the series > > as a whole. > > Hi Michel, > > Thanks for reviewing this series. > > > I think these changes are a big step in the right direction. My main > > reservation about them is that they are additive - adding some complexity > > for speculative page faults - and I wonder if it'd be possible, over the > > long term, to replace the existing complexity we have in mmap_sem retry > > mechanisms instead of adding to it. This is not something that should > > block your progress, but I think it would be good, as we introduce spf, > > to evaluate whether we could eventually get all the way to removing the > > mmap_sem retry mechanism, or if we will actually have to keep both. > > Until we get rid of the mmap_sem which seems to be a very long story, I > can't see how we could get rid of the retry mechanism. Short answer: I'd like spf to be extended to handle file vmas, populating page tables, and the vm_normal_page thing, so that we wouldn't have to fall back to the path that grabs (and possibly has to drop) the read side mmap_sem. Even doing the above, there are still cases spf can't solve - for example, gup, or the occasional spf abort, or even the case of a large mmap/munmap delaying a smaller one. I think replacing mmap_sem with a reader/writer interval lock would be a very nice generic solution to this problem, allowing false conflicts to proceed in parallel, while synchronizing true conflicts which is exactly what we want. But I don't think such a lock can be implemented efficiently enough to be put on the page fault fast-path, so I think spf could be the solution there - it would allow us to skip taking that interval lock on most page faults. The other places where we use mmap_sem are not as critical for performance (they normally operate on a larger region at a time) so I think we could afford the interval lock in those places. -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies.
