Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Sep 2008 19:08:44 +0200
From:      Rafal Jaworowski <raj@semihalf.com>
To:        Marcel Moolenaar <xcllnt@mac.com>
Cc:        freebsd-ppc@freebsd.org
Subject:   Re: 64-bit atomic ops on 32-bit CPU -- was: ZFS .. on PowerPC ?
Message-ID:  <48DBC59C.3040101@semihalf.com>
In-Reply-To: <111399E3-2BC7-4724-8AFB-A40F2A47E66D@mac.com>
References:  <B4645B39-9D9D-49C5-8F69-55704CD2F6AA@delfi-konsult.com> <60ACBA3B-927C-4F2C-8680-A6B40B81E06C@mac.com> <48DA84D5.4010109@semihalf.com> <C725D17E-E199-4E70-BE56-07BD21783A7A@mac.com> <48DA99F8.7070904@semihalf.com> <111399E3-2BC7-4724-8AFB-A40F2A47E66D@mac.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48DBC59C.3040101>