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 <t...@linutronix.de>
> Suggested-by: David Rientjes <rient...@google.com>
> Signed-off-by: Laurent Dufour <lduf...@linux.vnet.ibm.com>
> ---
>  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
> 

Reply via email to