Re: [PATCH v12 01/31] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

[Laurent Dufour]

Le 18/04/2019 Ã 23:47, Jerome Glisse a ÃcritÂ:
> On Tue, Apr 16, 2019 at 03:44:52PM +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, ARCH_HAS_PTE_SPECIAL, SMP and MMU.
> >
> > The architecture support is needed since the speculative page fault handler
> > is called from the architecture's page faulting code, and some code has to
> > be added there to handle the speculative handler.
> >
> > The dependency on ARCH_HAS_PTE_SPECIAL is required because vm_normal_page()
> > does processing that is not compatible with the speculative handling in the
> > case ARCH_HAS_PTE_SPECIAL is not set.
> >
> > Suggested-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> > Suggested-by: David Rientjes <rientjes@xxxxxxxxxx>
> > Signed-off-by: Laurent Dufour <ldufour@xxxxxxxxxxxxx>
>
> Reviewed-by: JÃrÃme Glisse <jglisse@xxxxxxxxxx>

Thanks JÃrÃme.

> Small question below
>
> > ---
> >   mm/Kconfig | 22 ++++++++++++++++++++++
> >   1 file changed, 22 insertions(+)
> >
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index 0eada3f818fa..ff278ac9978a 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -761,4 +761,26 @@ config GUP_BENCHMARK
> >   config ARCH_HAS_PTE_SPECIAL
> >   	bool
> >   
> > +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 ARCH_HAS_PTE_SPECIAL && MMU && SMP
> > +	help
> > +	  Try to handle user space page faults without holding the mmap_sem.
> > +
> > +	  This should allow better concurrency for massively threaded processes
>
> Is there any case where it does not provide better concurrency ? The
> should make me wonder :)

Depending on the VMA's type, it may not provide better concurrency. 
Indeed only anonymous mapping are managed currently. Perhaps this should 
be mentioned here, is it ?

> > +	  since the page fault handler will not wait for other thread's 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 a concurrent modification
> > +	  is detected or because underlying PMD or PTE tables are not yet
> > +	  allocated, the speculative page fault fails and a classic page fault
> > +	  is then tried.
> > +
> >   endmenu
> > --
> > 2.21.0