From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1030263AbbENR5h (ORCPT <rfc822;w@1wt.eu>);
	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
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 14 May 2015 13:57:34 -0400
Date: Thu, 14 May 2015 19:57:29 +0200
From: Ingo Molnar <mingo@kernel.org>
To: =?iso-8859-1?B?IkphbiBILiBTY2j2bmhlcnIi?= <jschoenh@amazon.de>
Cc: Len Brown <lenb@kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
        X86 ML <x86@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Anthony Liguori <aliguori@amazon.com>, Ingo Molnar <mingo@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Tim Deegan <tim@xen.org>,
        Gang Wei <gang.wei@intel.com>,
        Linus Torvalds <torvalds@linux-foundation.org>
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>
 <CAJvTdKkO+5DG83bTY+rD294q2ZechPLs384kbL6oz8rhLyPTOg@mail.gmail.com>
 <20150507102351.GA14347@gmail.com>
 <CAJvTdKk9NZ7-jcJARBNhfTh1O_mV=xgZkN0e84ajPVq=4pciiQ@mail.gmail.com>
 <CAJvTdKmJr70DYAjDs-38PzEUSNpn1ncXxR_csFw3a724egHnZQ@mail.gmail.com>
 <CAJvTdKn9scxP52FycyFaROdhhwbn-1V08SvMi2RJkykD79sDKA@mail.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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* "Jan H. Schönherr" <jschoenh@amazon.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