On Thu, 10 May 2001, Frank Rowand wrote:

Gabriel Paubert wrote:

quoted

On Wed, 9 May 2001, Brian Kuschak wrote:

quoted

quoted

static __inline__ void atomic_set(atomic_t *v, int a)
{
c004f9e8:       38 00 00 01     li      r0,1
        int t;

        __asm__ __volatile__("\n\
c004f9ec:       7d 60 f8 28     lwarx   r11,r0,r31
c004f9f0:       60 0b 00 00     ori     r11,r0,0
c004f9f4:       7d 60 f9 2d     stwcx.  r11,r0,r31
c004f9f8:       40 a2 ff f4     bne-    c004f9ec <d_alloc+0x90>

        atomic_set(&dentry->d_count, 1);

Is there any reason for atomic_set to use this sequence. I believe that a
simple store (stw in this case) would be ok. This looks like a very
convoluted and bloated way to set a variable. An aligned stw is guaranteed
to set the variable atomically wrt all other processors.

Sorry I wasn't around for the beginning of this discussion (I was off with
visiting family...), but I'll jump in now.

I put this version of atomic_set() into Brian's source.  It is one of the
things that helped reduce the severity of the dcache symptoms.  You can't
just use a stw in atomic_set(), because the other atomic operations depend
upon the stwcx.

Why not ? I'd like to find an explanation of a possible failure mode.
All PPC systems have always used a simple store for atomic_set. If it does
not work, there is something seriously wrong, perhaps even a hardware bug.

This is especially true on a UP system. Whatever value is stored by a stw
should be seen by any following lwarx/stwcx., on SMP you may need an
eieio. But on UP I can't see how it can affect anything.

Did it actually have any effect on Brian's system ?

	Gabriel.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/