[lkml]   [2017]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    SubjectRe: [PATCH v3 00/20] Speculative page faults
    Hi Andrew,

    On 28/09/2017 22:38, Andrew Morton wrote:
    > On Thu, 28 Sep 2017 14:29:02 +0200 Laurent Dufour <> wrote:
    >>> Laurent's [0/n] provides some nice-looking performance benefits for
    >>> workloads which are chosen to show performance benefits(!) but, alas,
    >>> no quantitative testing results for workloads which we may suspect will
    >>> be harmed by the changes(?). Even things as simple as impact upon
    >>> single-threaded pagefault-intensive workloads and its effect upon
    >>> CONFIG_SMP=n .text size?
    >> I forgot to mention in my previous email the impact on the .text section.
    >> Here are the metrics I got :
    >> .text size UP SMP Delta
    >> 4.13-mmotm 8444201 8964137 6.16%
    >> '' +spf 8452041 8971929 6.15%
    >> Delta 0.09% 0.09%
    >> No major impact as you could see.
    > 8k text increase seems rather a lot actually. That's a lot more
    > userspace cacheclines that get evicted during a fault...
    > Is the feature actually beneficial on uniprocessor?

    This is useless on uniprocessor, and I will disable it on x86 when !SMP
    by not defining __HAVE_ARCH_CALL_SPF.
    So the speculative page fault handler will not be built but the vm
    sequence counter and the SCRU stuff will still be there. I may also make
    it disabled through macro when __HAVE_ARCH_CALL_SPF is not defined, but
    this may obfuscated the code a bit...

    On ppc64, as this feature requires book3s, it can't be built without SMP

    I rebuild the code on my x86 guest with the following patch applied:
    --- a/arch/x86/include/asm/pgtable_types.h
    +++ b/arch/x86/include/asm/pgtable_types.h
    @@ -260,7 +260,7 @@ enum page_cache_mode {
    * Advertise that we call the Speculative Page Fault handler.
    -#ifdef CONFIG_X86_64
    +#if defined(CONFIG_X86_64) && defined(CONFIG_SMP)
    #define __HAVE_ARCH_CALL_SPF

    And this time I got the following size on UP :
    4.13-mmotm 8444201
    '' +spf 8447945 (previously 8452041)
    If I disable all the vm_sequence operations and the SRCU stuff this
    would lead to 0.


     \ /
      Last update: 2017-09-29 17:29    [W:3.194 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site