From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-tul01m020-f179.google.com (mail-tul01m020-f179.google.com [209.85.214.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (not verified)) by ozlabs.org (Postfix) with ESMTPS id CCD5A1007D1 for ; Wed, 15 Feb 2012 03:01:15 +1100 (EST) Received: by obbup6 with SMTP id up6so126841obb.38 for ; Tue, 14 Feb 2012 08:01:13 -0800 (PST) References: <20120130205444.22f5e26a@infradead.org> <20120131125232.GD4408@elte.hu> <20120131054155.371e8307@infradead.org> <20120131143130.GF13676@elte.hu> <20120131072216.1ce78e50@infradead.org> <20120131161207.GA18357@elte.hu> <20120131082439.575978c0@infradead.org> <4F3A1891.8060001@linux.vnet.ibm.com> <4F3A2DFB.5000209@linux.vnet.ibm.com> <1329232814.2293.7.camel@twins> In-Reply-To: <1329232814.2293.7.camel@twins> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----DZZ16CRZC4ZGWWUMWJK89K065RC5A7" Subject: Re: smp: Start up non-boot CPUs asynchronously From: Arjan van de Ven Date: Tue, 14 Feb 2012 08:01:04 -0800 To: Peter Zijlstra Message-ID: <5b5fa04c-492b-4566-929e-5c92dc7916fc@email.android.com> Cc: Stephen Rothwell , mikey@neuling.org, gregkh@linuxfoundation.org, Ingo Molnar , linux-kernel@vger.kernel.org, Milton Miller , Srivatsa Vaddagiri , Linus Torvalds , Arjan van de Ven , "Srivatsa S. Bhat" , "H. Peter Anvin" , Thomas Gleixner , "Paul E. McKenney" , ppc-dev , Andrew Morton , Arjan van de Ven List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , ------DZZ16CRZC4ZGWWUMWJK89K065RC5A7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Its more than acpi ... machine checks can do it too etc -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Peter Zijlstra wrote: On Tue, 2012-02-14 at 06:31 -0800, Arjan van de Ven wrote: > > frankly, such code HAS to worry about cpus going online and offline > even today; the firmware, at least on X86, can start taking cores > offline/online once ACPI is initialized.... (as controlled by a data > center manager from outside the box, usually done based on thermal or > power conditions on a datacenter level). Now, no doubt that we have > bugs in this space, since this only happened very rarely before. Which frankly is an utter piece of crap, that ACPI spec is total garbage and completely useless. You might have noticed that the ACPI code supporting that failure carries a big nacked-by from me. That's not to say we shouldn't try to fix hotplug, but bringing that ACPI nonsense to the table makes me care less, not more. I mean, really, that spec is broken, the support is worse. ------DZZ16CRZC4ZGWWUMWJK89K065RC5A7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Its more than acpi ... machine checks can do it too etc
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
On Tue, 2012-02-14 at 06:31 -0800, Arjan van de Ven wrote:
> 
> frankly, such code HAS to worry about cpus going online and offline
> even today; the firmware, at least on X86, can start taking cores
> offline/online once ACPI is initialized.... (as controlled by a data
> center manager from outside the box, usually done based on thermal or
> power conditions on a datacenter level). Now, no doubt that we have
> bugs in this space, since this only happened very rarely before. 

Which frankly is an utter piece of crap, that ACPI spec is total garbage
and completely useless. You might have noticed that the ACPI code
supporting that failure carries a big nacked-by from me.

That's not to say we shouldn't try to fix hotplug, but bringing that
ACPI nonsense to the table makes me care less, not more.

I mean,
really, that spec is broken, the support is worse.
------DZZ16CRZC4ZGWWUMWJK89K065RC5A7--