From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH 3/4] x86/nmi: wait for all CPUs in check_nmi_watchdog() Date: Wed, 14 May 2014 15:33:49 +0100 Message-ID: <53739AED020000780001242C@mail.emea.novell.com> References: <1400072299-2285-1-git-send-email-david.vrabel@citrix.com> <1400072299-2285-4-git-send-email-david.vrabel@citrix.com> <537392FE02000078000123AD@mail.emea.novell.com> <5373791A.4070506@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WkaFo-0005da-Im for xen-devel@lists.xenproject.org; Wed, 14 May 2014 14:33:56 +0000 In-Reply-To: <5373791A.4070506@citrix.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: David Vrabel Cc: AndrewCooper , Keir Fraser , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org >>> On 14.05.14 at 16:09, wrote: > x86/nmi: wait for all CPUs in check_nmi_watchdog() > > The counting of a CPUs NMIs in check_nmi_watchdog() is only reliable > if all CPUs have been spinning for 5 or more ticks. Whilst its highly > implausible that this won't happen in practise, explicitly wait so it's > clear that this is required. The thing is that I actually consider the early continuation to be desirable - there's no need for the BP to actually wait for the APs to finish their wait loop, as long as they progressed far enough into it. If you added a flag telling the others to bail as soon as the master exited its waiting, that would look more acceptable to me. Agreed we're not talking about big time differences here, but we shouldn't be making booting slower than it needs to be. Btw., did you check how modern Linux deals with the same issue (last I looked was many releases ago)? Jan