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  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:   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



Powered by blists - more mailing lists