Date: Mon, 25 May 2015 12:33:48 -0400 From: John Baldwin <jhb@freebsd.org> To: Ian Lepore <ian@freebsd.org> Cc: Andrew Turner <andrew@fubar.geek.nz>, Andrew Turner <andrew@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r283331 - head/sys/arm/arm Message-ID: <1756258.Dk05pRRcTN@ralph.baldwin.cx> In-Reply-To: <1432566566.1200.37.camel@freebsd.org> References: <201505232228.t4NMSxs2032365@svn.freebsd.org> <3083392.nvUXfWWOav@ralph.baldwin.cx> <1432566566.1200.37.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, May 25, 2015 09:09:26 AM Ian Lepore wrote: > On Mon, 2015-05-25 at 10:31 -0400, John Baldwin wrote: > > Mmmm, does that mean then that you can (conceivably) lose the race the other > > way where it "sees" ap_ready's update before it calls wfe and never calls > > wfe to "harvest" the event from sev? (In practice I think this is not > > possible during boot as AP's can't get preempted and there is typically > > a "long" time between AP's being signalled to start and start_aps being > > set. However, this would be a concern for use of wfe/sev for other use > > cases such as for the cpu_idle hook perhaps?) > > > > That's the "you must be prepared to handle spurious wakeups" part of the > sev/wfe contract. The point of WFE is only power-saving, so if your > loop spins one time due to an unharvested prior event flag still set, > that's deemed harmless. (Userland is allowed to issue SEV instructions, > which always target all cores, so there's no expectation of 1:1 relation > between sending and waiting.) Ok, good to know. Thanks! -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1756258.Dk05pRRcTN>