From owner-freebsd-ppc@FreeBSD.ORG Tue Sep 30 21:01:45 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 311411065693 for ; Tue, 30 Sep 2008 21:01:45 +0000 (UTC) (envelope-from neko@genesi-usa.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id DCC758FC0C for ; Tue, 30 Sep 2008 21:01:44 +0000 (UTC) (envelope-from neko@genesi-usa.com) Received: by qw-out-2122.google.com with SMTP id 9so57191qwb.7 for ; Tue, 30 Sep 2008 14:01:44 -0700 (PDT) Received: by 10.214.244.9 with SMTP id r9mr7105045qah.76.1222807129589; Tue, 30 Sep 2008 13:38:49 -0700 (PDT) Received: from ?131.194.34.47? ([131.194.34.47]) by mx.google.com with ESMTPS id 6sm787995qwk.1.2008.09.30.13.38.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Sep 2008 13:38:48 -0700 (PDT) Message-ID: <48E28E58.1020901@genesi-usa.com> Date: Tue, 30 Sep 2008 15:38:48 -0500 From: Matt Sealey User-Agent: Thunderbird 2.0.0.18pre (Windows/20080930) MIME-Version: 1.0 To: Rafal Jaworowski References: <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> <48DA84D5.4010109@semihalf.com> <48DA99F8.7070904@semihalf.com> <111399E3-2BC7-4724-8AFB-A40F2A47E66D@mac.com> <48DBC59C.3040101@semihalf.com> In-Reply-To: <48DBC59C.3040101@semihalf.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: Matt Sealey 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: Tue, 30 Sep 2008 21:01:45 -0000 Isn't there some kind of semaphore primitive in FreeBSD that can be used? I don't understand why you would need to go for all this effort when every atomic-access-requiring variable can simply just be paired with a lock flag (atomic_a and atomic_a_sem). You ask for the semaphore, if you get it, you can write into the value and read from the value, if you do not, you wait until you can get the semaphore.. After all you are basically just implementing a cache-line-sized integrated variable and a new semaphore system here, is NIH really that big a problem? -- Matt Sealey Genesi, Manager, Developer Relations Rafal Jaworowski wrote: > Marcel Moolenaar wrote: >>> 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 >> Ok. Let's assume we lose the reservation and we're >> forced to loop and try again. Step 2 then reads W2, >> which on a retry is the word written in step 4. As >> such, if we have to loop and retry X times, then >> the atomic increment would increment by X and not >> 1. >> >> I don't think an unconditional write to W2 will >> work if we don't preserve the origional value of >> W2. > > Yeah, it seems there are problems with W2 in read-modify-write scenarios... My > environment is simpler (don't need full R-M-W facility). Let me think a bit > about that other algo. > > FWIW, on multicore e500 systems it is possible to do this safely: there is > system wide atomic op monitoring bit HID1[ATS], which lets a given CPU know if > a lwarx/stwcx sequence is in progress on the system, so we can remotely manage > reservations and eliminate wasting some of bus bandwidth. But this is of > course not uniform accross PowerPC implementations. > > Rafal > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org"