linux-kernel - Re: [PATCH v3 00/20] Speculative page faults

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 03 Oct 2017 12:27:10 +1100
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Laurent Dufour <ldufour@...ux.vnet.ibm.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Paul McKenney <paulmck@...ux.vnet.ibm.com>,
        Peter Zijlstra <peterz@...radead.org>, kirill@...temov.name,
        Andi Kleen <ak@...ux.intel.com>,
        Michal Hocko <mhocko@...nel.org>, dave@...olabs.net,
        Jan Kara <jack@...e.cz>, Matthew Wilcox <willy@...radead.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Will Deacon <will.deacon@....com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>, haren@...ux.vnet.ibm.com,
        Anshuman Khandual <khandual@...ux.vnet.ibm.com>,
        npiggin@...il.com, bsingharora@...il.com,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        linuxppc-dev@...ts.ozlabs.org, "x86\@kernel.org" <x86@...nel.org>
Subject: Re: [PATCH v3 00/20] Speculative page faults

Laurent Dufour <ldufour@...ux.vnet.ibm.com> writes:

> Hi Andrew,
>
> On 28/09/2017 22:38, Andrew Morton wrote:
>> On Thu, 28 Sep 2017 14:29:02 +0200 Laurent Dufour <ldufour@...ux.vnet.ibm.com> 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 
> support.

Book3S doesn't force SMP, eg. PMAC is Book3S but can be built with SMP=n.

It's true that POWERNV and PSERIES both force SMP, and those are the
platforms used on modern Book3S CPUs.

cheers