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]

Date:	Thu, 14 May 2015 19:57:29 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	"Jan H. Schönherr" <jschoenh@...zon.de>
Cc:	Len Brown <lenb@...nel.org>, 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


* "Jan H. Schönherr" <jschoenh@...zon.de> wrote:

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

So I'm not against improving this code at all, but instead of this 
hard to follow mixing of old and new code, I'd find the following 
approach cleaner and more acceptable: create a 'modern' and a 'legacy' 
SMP-bootup variant function, and do a clean separation based on the 
CPU model cutoff condition used by Len's patches:

        /* if modern processor, use no delay */
        if (((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) && (boot_cpu_data.x86 == 6)) ||
            ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) && (boot_cpu_data.x86 >= 0xF)))
                init_udelay = 0;

Then in the modern variant we can become even more aggressive and 
remove these kinds of delays as well:

                udelay(300);
                udelay(200);

plus I'd suggest making these poll loops in smpboot.c loops narrower:

                        udelay(100);

                        udelay(100);

because every iteration is 0.1 msecs - if we hit these poll loops then 
it adds up with a few dozen CPUs.

Thanks,

	Ingo
--
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/