Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933686AbbENO01 (ORCPT ); Thu, 14 May 2015 10:26:27 -0400 Received: from smtp-fw-9101.amazon.com ([207.171.184.25]:34860 "EHLO smtp-fw-9101.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932917AbbENO0J (ORCPT ); Thu, 14 May 2015 10:26:09 -0400 X-IronPort-AV: E=Sophos;i="5.13,429,1427760000"; d="scan'208";a="246636880" Message-ID: <5554B06E.8070607@amazon.de> Date: Thu, 14 May 2015 16:25:50 +0200 From: =?UTF-8?B?IkphbiBILiBTY2jDtm5oZXJyIg==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Len Brown , Ingo Molnar CC: 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 References: <1430732554-7294-1-git-send-email-jschoenh@amazon.de> <20150506082759.GA30019@gmail.com> <20150507102351.GA14347@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1466 Lines: 41 On 05/14/2015 09:18 AM, Len Brown wrote: > On Thu, May 14, 2015 at 2:36 AM, Len Brown 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/