Hi Laurent, I guess it's good timing to review. Guess LSF/MM goes so might change a lot since then. :) Anyway, I grap a time to review. On Tue, Apr 17, 2018 at 04:33:07PM +0200, Laurent Dufour wrote: > This configuration variable will be used to build the code needed to > handle speculative page fault. > > By default it is turned off, and activated depending on architecture > support, SMP and MMU. Can we have description in here why it depends on architecture? > > Suggested-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Suggested-by: David Rientjes <rientjes@xxxxxxxxxx> > Signed-off-by: Laurent Dufour <ldufour@xxxxxxxxxxxxxxxxxx> > --- > mm/Kconfig | 22 ++++++++++++++++++++++ > 1 file changed, 22 insertions(+) > > diff --git a/mm/Kconfig b/mm/Kconfig > index d5004d82a1d6..5484dca11199 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -752,3 +752,25 @@ config GUP_BENCHMARK > performance of get_user_pages_fast(). > > See tools/testing/selftests/vm/gup_benchmark.c > + > +config ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT > + def_bool n > + > +config SPECULATIVE_PAGE_FAULT > + bool "Speculative page faults" > + default y > + depends on ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT > + depends on MMU && SMP > + help > + Try to handle user space page faults without holding the mmap_sem. > + > + This should allow better concurrency for massively threaded process > + since the page fault handler will not wait for other threads memory > + layout change to be done, assuming that this change is done in another > + part of the process's memory space. This type of page fault is named > + speculative page fault. > + > + If the speculative page fault fails because of a concurrency is > + detected or because underlying PMD or PTE tables are not yet > + allocating, it is failing its processing and a classic page fault > + is then tried. > -- > 2.7.4 >
