Messages in this thread | | | Subject | Re: [PATCH v12 01/31] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT | From | Laurent Dufour <> | Date | Tue, 23 Apr 2019 17:21:37 +0200 |
| |
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 >> >
| |