From owner-svn-src-head@FreeBSD.ORG Mon May 25 11:45:14 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB2D385C; Mon, 25 May 2015 11:45:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 86A46E0; Mon, 25 May 2015 11:45:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 69FD3B9A3; Mon, 25 May 2015 07:45:13 -0400 (EDT) From: John Baldwin To: Andrew Turner Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r283331 - head/sys/arm/arm Date: Mon, 25 May 2015 07:23:28 -0400 Message-ID: <1484557.5zjnsBffEc@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.1-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <201505232228.t4NMSxs2032365@svn.freebsd.org> References: <201505232228.t4NMSxs2032365@svn.freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 25 May 2015 07:45:13 -0400 (EDT) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 11:45:14 -0000 On Saturday, May 23, 2015 10:28:59 PM Andrew Turner wrote: > Author: andrew > Date: Sat May 23 22:28:59 2015 > New Revision: 283331 > URL: https://svnweb.freebsd.org/changeset/base/283331 > > Log: > Use the wait-for-event instruction to put the core we have just enabled > to sleep while it waits to start scheduling. The boot core can then use > the send-event instruction to wake the cores when they should enter the > scheduler. > > MFC after: 1 week > > Modified: > head/sys/arm/arm/mp_machdep.c > > Modified: head/sys/arm/arm/mp_machdep.c > ============================================================================== > --- head/sys/arm/arm/mp_machdep.c Sat May 23 21:58:41 2015 (r283330) > +++ head/sys/arm/arm/mp_machdep.c Sat May 23 22:28:59 2015 (r283331) > @@ -185,8 +185,11 @@ init_secondary(int cpu) > atomic_add_rel_32(&mp_naps, 1); > > /* Spin until the BSP releases the APs */ > - while (!aps_ready) > - ; > + while (!atomic_load_acq_int(&aps_ready)) { > +#if __ARM_ARCH >= 7 > + __asm __volatile("wfe"); > +#endif > + } I don't know that this atomic load acquire is really changing anything here? Since aps_ready is volatile reading it should already be "atomic" on each check around the loop. > /* Initialize curthread */ > KASSERT(PCPU_GET(idlethread) != NULL, ("no idle thread")); > @@ -353,6 +356,10 @@ release_aps(void *dummy __unused) > arm_unmask_irq(i); > } > atomic_store_rel_int(&aps_ready, 1); > + /* Wake the other threads up */ > +#if __ARM_ARCH >= 7 > + armv7_sev(); > +#endif So I'm not at all familiar with these instructions or what they do, but are the events level triggered? In particular, is there any sort of race where the sev might arrive in between the check of aps_ready and the wfe on an AP? (For example, if wfe/sev were similar to using mwait on x86 for wfe and a memory write for sev, x86 would require a call to monitor before doing a check of aps_ready to handle the race like so: while (!aps_ready) { monitor(&aps_ready); if (!aps_ready) mwait(); } -- John Baldwin