linux-kernel - Re: [PATCH] x86: skip delays during SMP initialization similar to Xen

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: <5554B06E.8070607@amazon.de>
Date:	Thu, 14 May 2015 16:25:50 +0200
From:	"Jan H. Schönherr" <jschoenh@...zon.de>
To:	Len Brown <lenb@...nel.org>, Ingo Molnar <mingo@...nel.org>
CC:	Thomas Gleixner <tglx@...utronix.de>, X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Anthony Liguori <aliguori@...zon.com>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Tim Deegan <tim@....org>,
	Gang Wei <gang.wei@...el.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] x86: skip delays during SMP initialization similar to
 Xen

On 05/14/2015 09:18 AM, Len Brown wrote:
> On Thu, May 14, 2015 at 2:36 AM, Len Brown <lenb@...nel.org> wrote:
>
>>> [    2.737884] x86: Booted up 4 nodes, 120 CPUs
>
>> For the record, the same (bare metal) box running latest tip boots
>> 10ms/processor quicker
>
>> [    1.553658] x86: Booted up 4 nodes, 120 CPUs
>
>> BTW. this time can be reduced by 7% (113 ms) by deleting announce_cpu():
>>
>> [    1.445815] x86: Booted up 4 nodes, 120 CPUs
>
> I see that the x2apic optimization has been reverted from TIP.

Gone as fast as it came. I learned that having an x2apic is different
from using code written for it. (And I'll try not to repeat something
like that.)

> So just for grins, I booted the same box with all the udelays in
> smpboot.c removed,
> and it speed up boot by only 12ms (0.8%) total:
>
> [    1.432946] x86: Booted up 4 nodes, 120 CPUs

Is that on top of deleting announce_cpu() or instead? Because I would
have expected more than 12ms improvement just by summing up the
udelay()s.

Ingo, do you want an updated version of the original patch, which
takes care not get stuck, when the INIT deassertion is skipped,
or do you prefer to address delays "one by one" as you wrote elsewhere?

Regards
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/