From owner-freebsd-ppc@FreeBSD.ORG Wed Sep 24 19:50:24 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B876106566B for ; Wed, 24 Sep 2008 19:50:24 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from semihalf.com (semihalf.com [206.130.101.55]) by mx1.freebsd.org (Postfix) with ESMTP id 78C5B8FC2D for ; Wed, 24 Sep 2008 19:50:24 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by semihalf.com (8.13.1/8.13.1) with ESMTP id m8OJoMvc018670; Wed, 24 Sep 2008 13:50:23 -0600 Received: from [77.114.152.246] (apn-77-114-152-246.gprs.plus.pl [77.114.152.246]) by mail.semihalf.com (Postfix) with ESMTP id 186F41478E; Wed, 24 Sep 2008 22:00:30 +0200 (CEST) Message-ID: <48DA99F8.7070904@semihalf.com> Date: Wed, 24 Sep 2008 21:50:16 +0200 From: Rafal Jaworowski Organization: Semihalf MIME-Version: 1.0 To: Marcel Moolenaar References: <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> <48DA84D5.4010109@semihalf.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-ppc@freebsd.org Subject: Re: 64-bit atomic ops on 32-bit CPU -- was: ZFS .. on PowerPC ? X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2008 19:50:24 -0000 Marcel Moolenaar wrote: >> a.) make sure the whole granule is dedicated for a single object we want >> atomic access to, i.e. in case of a 64-bit object we would use only 2 >> words >> out of 8 in the given granule and the remaining 6 would be wasted > > Is this required for correctness? I can see that it is > desirable for performance, but I don't think it's needed > for correctness. Can you elaborate? Having a dedicated granule for the object is not requirement. If this is not met the reservation may be lost gratuitously due to other stores which might happen within this granule (issued by other CPUs, and/or other threads on local CPU doing stwcx in this granule). So this is would hit performance, as you note, but the scheme would work still. The strict requirement is having all words of the compound atomic object within the same granule. >> Atomic store skeleton (pseudo asm, but you'll get the idea): >> >> 1. lwarx W1 >> >> 2. stw W2 >> This regular (non-stwcx) store issued from local CPU will not clear our >> reservation on this granule (only external CPUs or other entities' stores >> within this granule can clear it) >> >> 3. stwcx W1, goto p.1 if not succeeded > > I don't see a read of W2. In particular, we clobber W2 > unconditionally, so we must guarantee that we always > read the correct value of W2. Can you elaborate on how > an increment would be made atomic? This was an example of an atomic write when we don't care about the previous state (there, the initial lwarx is only needed for obtaining the reservation). Atomic increment would be like this: 1. lwarx W1 2. lwz W2 3. In-register increment/other modification 4. stw W2 (modified) Neither 2. nor 3 issued from local CPU will not clear our reservation on this granule. (optionally increment/modify in-register value of W1) 5. stwcx W1, goto p.1 if not succeeded If non-local CPU (or any other bus master) modifies anything within the considered granule after we obtained the reservation in 1., the last stwcx will fail and we'll loop again. Rafal