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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ