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

From: Laurent Dufour
Date: Tue Oct 03 2017 - 04:03:58 EST

On 03/10/2017 03:27, Michael Ellerman wrote:
> Laurent Dufour <ldufour@xxxxxxxxxxxxxxxxxx> writes:
>> Hi Andrew,
>> On 28/09/2017 22:38, Andrew Morton wrote:
>>> On Thu, 28 Sep 2017 14:29:02 +0200 Laurent Dufour <ldufour@xxxxxxxxxxxxxxxxxx> 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.

Thanks Michael,

I'll add a check on CONFIG_SMP on ppc too.