lkml.org 
[lkml]   [2018]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v9 01/24] mm: Introduce CONFIG_SPECULATIVE_PAGE_FAULT
On Wed, 28 Mar 2018, Laurent Dufour wrote:

> > Putting this in mm/Kconfig is definitely the right way to go about it
> > instead of any generic option in arch/*.
> >
> > My question, though, was making this configurable by the user:
> >
> > config SPECULATIVE_PAGE_FAULT
> > bool "Speculative page faults"
> > depends on X86_64 || PPC
> > default y
> > help
> > ..
> >
> > It's a question about whether we want this always enabled on x86_64 and
> > power or whether the user should be able to disable it (right now they
> > can't). With a large feature like this, you may want to offer something
> > simple (disable CONFIG_SPECULATIVE_PAGE_FAULT) if someone runs into
> > regressions.
>
> I agree, but I think it would be important to get the per architecture
> enablement to avoid complex check here. For instance in the case of powerPC
> this is only supported for PPC_BOOK3S_64.
>
> To avoid exposing such per architecture define here, what do you think about
> having supporting architectures setting ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT
> and the SPECULATIVE_PAGE_FAULT depends on this, like this:
>
> In mm/Kconfig:
> config SPECULATIVE_PAGE_FAULT
> bool "Speculative page faults"
> depends on ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT && SMP
> default y
> help
> ...
>
> In arch/powerpc/Kconfig:
> config PPC
> ...
> select ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT if PPC_BOOK3S_64
>
> In arch/x86/Kconfig:
> config X86_64
> ...
> select ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT
>
>

Looks good to me! It feels like this will add more assurance that if
things regress for certain workloads that it can be disabled. I don't
feel strongly about the default value, I'm ok with it being enabled by
default.

\
 
 \ /
  Last update: 2018-03-28 23:18    [W:0.142 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site