[FIX PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

[Laurent Dufour]

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 
Suggested-by: David Rientjes 
Signed-off-by: Laurent Dufour 
---
 mm/Kconfig | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/mm/Kconfig b/mm/Kconfig
index 1d0888c5b97a..d958fd8ce73a 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -761,3 +761,25 @@ 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.
-- 
2.7.4

[FIX PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

[Laurent Dufour]

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 
Suggested-by: David Rientjes 
Signed-off-by: Laurent Dufour 
---
 mm/Kconfig | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/mm/Kconfig b/mm/Kconfig
index 1d0888c5b97a..d958fd8ce73a 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -761,3 +761,25 @@ 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.
-- 
2.7.4

Re: [PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

[Laurent Dufour]

On 17/05/2018 18:36, Randy Dunlap wrote:
> Hi,
> 
> On 05/17/2018 04:06 AM, 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 
>> Suggested-by: David Rientjes 
>> Signed-off-by: Laurent Dufour 
>> ---
>>  mm/Kconfig | 22 ++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index 1d0888c5b97a..a38796276113 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -761,3 +761,25 @@ 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 process
> 
>processes
> 
>> + since the page fault handler will not wait for other threads memory
> 
> thread's
> 
>> + 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
> 
>because 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
> 
>allocated, the speculative page fault fails and a classic page fault
> 
>> + is then tried.
> 
> 
> Also, all of the help text (below the "help" line) should be indented by
> 1 tab + 2 spaces (in coding-style.rst).

Thanks, Randy for reviewing my miserable English grammar.
I'll fix that and the indentation.

Re: [PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

[Laurent Dufour]

On 17/05/2018 18:36, Randy Dunlap wrote:
> Hi,
> 
> On 05/17/2018 04:06 AM, 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 
>> Suggested-by: David Rientjes 
>> Signed-off-by: Laurent Dufour 
>> ---
>>  mm/Kconfig | 22 ++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index 1d0888c5b97a..a38796276113 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -761,3 +761,25 @@ 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 process
> 
>processes
> 
>> + since the page fault handler will not wait for other threads memory
> 
> thread's
> 
>> + 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
> 
>because 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
> 
>allocated, the speculative page fault fails and a classic page fault
> 
>> + is then tried.
> 
> 
> Also, all of the help text (below the "help" line) should be indented by
> 1 tab + 2 spaces (in coding-style.rst).

Thanks, Randy for reviewing my miserable English grammar.
I'll fix that and the indentation.

Re: [PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

[Laurent Dufour]

On 17/05/2018 19:19, Matthew Wilcox wrote:
> On Thu, May 17, 2018 at 09:36:00AM -0700, Randy Dunlap wrote:
>>> +If the speculative page fault fails because of a concurrency is
>>
>>   because a concurrency is
> 
> While one can use concurrency as a noun, it sounds archaic to me.  I'd
> rather:
> 
>   If the speculative page fault fails because a concurrent modification
>   is detected or because underlying PMD or PTE tables are not yet

Thanks Matthew, I'll do that.

> 
>>> +detected or because underlying PMD or PTE tables are not yet
>>> +allocating, it is failing its processing and a classic page fault
>>
>>   allocated, the speculative page fault fails and a classic page fault
>>
>>> +is then tried.
> 

Re: [PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

[Laurent Dufour]

On 17/05/2018 19:19, Matthew Wilcox wrote:
> On Thu, May 17, 2018 at 09:36:00AM -0700, Randy Dunlap wrote:
>>> +If the speculative page fault fails because of a concurrency is
>>
>>   because a concurrency is
> 
> While one can use concurrency as a noun, it sounds archaic to me.  I'd
> rather:
> 
>   If the speculative page fault fails because a concurrent modification
>   is detected or because underlying PMD or PTE tables are not yet

Thanks Matthew, I'll do that.

> 
>>> +detected or because underlying PMD or PTE tables are not yet
>>> +allocating, it is failing its processing and a classic page fault
>>
>>   allocated, the speculative page fault fails and a classic page fault
>>
>>> +is then tried.
> 

Re: [PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

[Randy Dunlap]

On 05/17/2018 10:19 AM, Matthew Wilcox wrote:
> On Thu, May 17, 2018 at 09:36:00AM -0700, Randy Dunlap wrote:
>>> +If the speculative page fault fails because of a concurrency is
>>
>>   because a concurrency is
> 
> While one can use concurrency as a noun, it sounds archaic to me.  I'd
> rather:
> 
>   If the speculative page fault fails because a concurrent modification
>   is detected or because underlying PMD or PTE tables are not yet

Yeah, OK.

>>> +detected or because underlying PMD or PTE tables are not yet
>>> +allocating, it is failing its processing and a classic page fault
>>
>>   allocated, the speculative page fault fails and a classic page fault
>>
>>> +is then tried.


-- 
~Randy

Re: [PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

[Randy Dunlap]

On 05/17/2018 10:19 AM, Matthew Wilcox wrote:
> On Thu, May 17, 2018 at 09:36:00AM -0700, Randy Dunlap wrote:
>>> +If the speculative page fault fails because of a concurrency is
>>
>>   because a concurrency is
> 
> While one can use concurrency as a noun, it sounds archaic to me.  I'd
> rather:
> 
>   If the speculative page fault fails because a concurrent modification
>   is detected or because underlying PMD or PTE tables are not yet

Yeah, OK.

>>> +detected or because underlying PMD or PTE tables are not yet
>>> +allocating, it is failing its processing and a classic page fault
>>
>>   allocated, the speculative page fault fails and a classic page fault
>>
>>> +is then tried.


-- 
~Randy

Re: [PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

[Matthew Wilcox]

On Thu, May 17, 2018 at 09:36:00AM -0700, Randy Dunlap wrote:
> > +If the speculative page fault fails because of a concurrency is
> 
>because a concurrency is

While one can use concurrency as a noun, it sounds archaic to me.  I'd
rather:

If the speculative page fault fails because a concurrent modification
is detected or because underlying PMD or PTE tables are not yet

> > +detected or because underlying PMD or PTE tables are not yet
> > +allocating, it is failing its processing and a classic page fault
> 
>allocated, the speculative page fault fails and a classic page fault
> 
> > +is then tried.

Re: [PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

[Matthew Wilcox]

On Thu, May 17, 2018 at 09:36:00AM -0700, Randy Dunlap wrote:
> > +If the speculative page fault fails because of a concurrency is
> 
>because a concurrency is

While one can use concurrency as a noun, it sounds archaic to me.  I'd
rather:

If the speculative page fault fails because a concurrent modification
is detected or because underlying PMD or PTE tables are not yet

> > +detected or because underlying PMD or PTE tables are not yet
> > +allocating, it is failing its processing and a classic page fault
> 
>allocated, the speculative page fault fails and a classic page fault
> 
> > +is then tried.

Re: [PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

[Randy Dunlap]

Hi,

On 05/17/2018 04:06 AM, 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 
> Suggested-by: David Rientjes 
> Signed-off-by: Laurent Dufour 
> ---
>  mm/Kconfig | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 1d0888c5b97a..a38796276113 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -761,3 +761,25 @@ 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 process

 processes

> +  since the page fault handler will not wait for other threads memory

  thread's

> +  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

 because 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

 allocated, the speculative page fault fails and a classic page fault

> +  is then tried.


Also, all of the help text (below the "help" line) should be indented by
1 tab + 2 spaces (in coding-style.rst).


-- 
~Randy

Re: [PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

[Randy Dunlap]

Hi,

On 05/17/2018 04:06 AM, 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 
> Suggested-by: David Rientjes 
> Signed-off-by: Laurent Dufour 
> ---
>  mm/Kconfig | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 1d0888c5b97a..a38796276113 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -761,3 +761,25 @@ 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 process

 processes

> +  since the page fault handler will not wait for other threads memory

  thread's

> +  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

 because 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

 allocated, the speculative page fault fails and a classic page fault

> +  is then tried.


Also, all of the help text (below the "help" line) should be indented by
1 tab + 2 spaces (in coding-style.rst).


-- 
~Randy

[PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

[Laurent Dufour]

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 
Suggested-by: David Rientjes 
Signed-off-by: Laurent Dufour 
---
 mm/Kconfig | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/mm/Kconfig b/mm/Kconfig
index 1d0888c5b97a..a38796276113 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -761,3 +761,25 @@ 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 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

[PATCH v11 01/26] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

[Laurent Dufour]

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 
Suggested-by: David Rientjes 
Signed-off-by: Laurent Dufour 
---
 mm/Kconfig | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/mm/Kconfig b/mm/Kconfig
index 1d0888c5b97a..a38796276113 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -761,3 +761,25 @@ 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 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