Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030263AbbENR5h (ORCPT ); Thu, 14 May 2015 13:57:37 -0400 Received: from mail-wg0-f43.google.com ([74.125.82.43]:33870 "EHLO mail-wg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030225AbbENR5e (ORCPT ); Thu, 14 May 2015 13:57:34 -0400 Date: Thu, 14 May 2015 19:57:29 +0200 From: Ingo Molnar To: =?iso-8859-1?B?IkphbiBILiBTY2j2bmhlcnIi?= Cc: Len Brown , Thomas Gleixner , X86 ML , "linux-kernel@vger.kernel.org" , Anthony Liguori , Ingo Molnar , "H. Peter Anvin" , Tim Deegan , Gang Wei , Linus Torvalds Subject: Re: [PATCH] x86: skip delays during SMP initialization similar to Xen Message-ID: <20150514175729.GA19960@gmail.com> References: <1430732554-7294-1-git-send-email-jschoenh@amazon.de> <20150506082759.GA30019@gmail.com> <20150507102351.GA14347@gmail.com> <5554B06E.8070607@amazon.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5554B06E.8070607@amazon.de> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1532 Lines: 41 * "Jan H. Sch?nherr" 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/