From owner-freebsd-current@freebsd.org  Fri Aug 21 16:53:26 2015
Return-Path: <owner-freebsd-current@freebsd.org>
Delivered-To: freebsd-current@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE1149BF060
 for <freebsd-current@mailman.ysv.freebsd.org>;
 Fri, 21 Aug 2015 16:53:26 +0000 (UTC)
 (envelope-from julian@freebsd.org)
Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "vps1.elischer.org",
 Issuer "CA Cert Signing Authority" (not verified))
 by mx1.freebsd.org (Postfix) with ESMTPS id 849FB1927;
 Fri, 21 Aug 2015 16:53:26 +0000 (UTC)
 (envelope-from julian@freebsd.org)
Received: from Julian-MBP3.local
 (ppp121-45-243-143.lns20.per4.internode.on.net [121.45.243.143])
 (authenticated bits=0)
 by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id t7LGrLeF048408
 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
 Fri, 21 Aug 2015 09:53:24 -0700 (PDT)
 (envelope-from julian@freebsd.org)
Subject: Re: freebsd-head: suddenly NMI panics lead to ddb being unable to
 stop CPUs?
To: Ian Lepore <ian@freebsd.org>
References: <CAJ-VmomvqULP--v47qKJisQkf8VQNvxEhXK=HXEtv9MuLz4D1g@mail.gmail.com>
 <CAFMmRNw6tWMQ-pfXzSpEM7kRgKafB9KnK-oUhWw2_E-P91drLw@mail.gmail.com>
 <55D74193.4020008@FreeBSD.org>
 <CAJ-Vmon6xXBSMPWgNhg-RZKLuuMDP1hvXG+DdZ3fZdvFnan06g@mail.gmail.com>
 <55D74402.70104@freebsd.org> <1440174193.242.279.camel@freebsd.org>
Cc: Adrian Chadd <adrian@freebsd.org>,
 freebsd-current <freebsd-current@freebsd.org>
From: Julian Elischer <julian@freebsd.org>
Message-ID: <55D7577B.8090000@freebsd.org>
Date: Sat, 22 Aug 2015 00:53:15 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <1440174193.242.279.camel@freebsd.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
 <freebsd-current.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Aug 2015 16:53:26 -0000

On 8/22/15 12:23 AM, Ian Lepore wrote:
> On Fri, 2015-08-21 at 23:30 +0800, Julian Elischer wrote:
>> On 8/21/15 11:25 PM, Adrian Chadd wrote:
>>> Ah, cool. I'll give it a whirl.
>>>
>>> I'm a little worried about having all of the other cores spinning in
>>> this case (mostly thermal; the machines get VERY LOUD when the CPUs
>>> are spinning..)
>>>
>> make each spin with the pause instruction.. and for N seconds (N being
>> the CPU ID) or something
> cpu_spinwait() is defined as ia32_pause() on i386 and amd64.
>
> The problem is that ONLY x86 arches benefit from cpu_spinwait(), it's
> just a nop on other arches, which turn into little radiant heaters for
> long spins (like while waiting for APs to be released).

remind me again why it cant spin with a 'halt' instruction?

>
> On ARM we have a really nice wait-for-event/signal-event pair of
> instructions, where WFE would be a natural for cpu_spinwait(), but would
> require a matching cpu_spinwake() type call to be sprinkled around to do
> the matching SEV instruction.
>
> -- Ian
>
>
>