linux-kernel - Re: [PATCH] use x86 cpu park to speedup smp

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]

Message-ID: <06977da1-d148-0079-0e85-32d657d1a1de@huawei.com>
Date:   Wed, 16 Dec 2020 22:18:31 +0800
From:   "shenkai (D)" <shenkai8@...wei.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Andy Lutomirski <luto@...nel.org>
CC:     LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        X86 ML <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
        <hewenliang4@...wei.com>, <hushiyuan@...wei.com>,
        <luolongjun@...wei.com>, <hejingxian@...wei.com>
Subject: Re: [PATCH] use x86 cpu park to speedup smp_init in kexec situation

在 2020/12/16 18:12, Thomas Gleixner 写道:
> Kai,
>
> On Wed, Dec 16 2020 at 16:45, shenkai wrote:
>> 在 2020/12/16 5:20, Thomas Gleixner 写道:
>>>
>> Thanks for your and Andy's precious comments. I would like to take a try on
>>
>> reconstructing this patch to make it more decent and generic.
>>> It would be interesting to see the numbers just with play_dead() using
>>> hlt() or mwait(eax=0, 0) for the kexec case and no other change at all.
> Can you please as a first step look into this and check if the time
> changes?
>
> Thanks,
>
>          tglx
> .

After some tests, the conclusion that time cost is from deep C-state 
turns out to be wrong

Sorry for that.

Here is what I do:

In kexec case, first let APs spinwait like what I did  in that patch, 
but wake APs up by

sending apic INIT and SIPI  interrupts as normal procedure instead of 
writing to some

address and there is no acceleration (time cost is still 210ms).

So can we say that the main time cost is from apic INIT and SIPI 
interrupts and the handling

of them instead of deep C-state?


I didn't test with play_dead() because in kexec case, one new kernel 
will be started and APs can't be

waken up by normal interrupts like in hibernate case for the irq vectors 
are gone with the old kernel.

Or maybe I didn't get the point correctly?


Best regards

Kai