On Mon, Feb 20, 2023 at 02:43:23PM +0000, Matthew Wilcox wrote: > On Mon, Feb 20, 2023 at 02:26:49PM +0000, Hyeonggon Yoo wrote: > > On Mon, Jan 02, 2023 at 02:37:02PM +0000, Matthew Wilcox wrote: > > > On Mon, Jan 02, 2023 at 09:04:12PM +0900, Hyeonggon Yoo wrote: > > > > > https://www.infradead.org/~willy/linux/store-free-page-faults.html > > > > > outlines how I intend to proceed from Suren's current scheme (where > > > > > RCU is only used to protect the tree walk) to using RCU for the > > > > > entire page fault. > > > > > > > > Thank you for sharing this your outlines. > > > > Okay, so the planned scheme is: > > > > > > > > 1. Try to process entire page fault under RCU protection > > > > - if failed, goto 2. if succeeded, goto 4. > > > > > > > > 2. Fall back to Suren's scheme (try to take VMA rwsem) > > > > - if failed, goto 3. if succeeded, goto 4. > > > > > > Right. The question is whether to restart the page fault under Suren's > > > scheme, or just grab the VMA rwsem and continue. Experimentation > > > needed. > > > > > > It's also worth noting that Michel has an alternative proposal, which > > > is to drop out of RCU protection before trying to allocate memory, then > > > re-enter RCU mode and check the sequence count hasn't changed on the > > > entire MM. His proposal has the advantage of not trying to allocate > > > memory while holding the RCU read lock, but the disadvantage of having > > > to retry the page fault if anyone has called mmap() or munmap(). Which > > > alternative is better is going to depend on the workload; do we see more > > > calls to mmap()/munmap(), or do we need to enter page reclaim more often? > > > I think they're largely equivalent performance-wise in the fast path. > > > Another metric to consider is code complexity; he thinks his method > > > is easier to understand and I think mine is easier. To be expected, > > > I suppose ;-) > > > > I'm planning to suggest a cooperative project to my colleagues > > that would involve making __p?d_alloc() take gfp flags. > > > > Wondering if there was any progress or conclusion made on which > > approach is better for full RCU page faults, or was there another > > solution proposed? > > > > Asking this because I don't want to waste my time if the approach > > has been abandoned. > > Thanks for checking, but nobody's made any progress on this, that I know > of. Thanks for confirmation. then I think it's still worth trying. > (The __p?d_alloc() approach may also be useful to support vmalloc() > with flags that aren't GFP_KERNEL compatible) Is there any possible users of that, sounds like someone tries to call __vmalloc() in interrupt context or RCU read-side critical section?
