| Message ID | 20190416134522.17540-2-ldufour@linux.ibm.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | Speculative page faults | expand |
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@linutronix.de> > Suggested-by: David Rientjes <rientjes@google.com> > Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com> Reviewed-by: Jérôme Glisse <jglisse@redhat.com> 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 :) > + 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 >
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@linutronix.de> >> Suggested-by: David Rientjes <rientjes@google.com> >> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com> > > Reviewed-by: Jérôme Glisse <jglisse@redhat.com> 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 >> >
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 + 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
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@linutronix.de> Suggested-by: David Rientjes <rientjes@google.com> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com> --- mm/Kconfig | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)