[parisc-linux] Re: [PATCH] Fix the atomic compare and swap

[John David Anglin]

> On 5/21/07, John David Anglin <dave at hiauly1.hia.nrc.ca> wrote:
> > > --- ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h.orig     2007-05-20 23:15:37.000000000 +0200
> > > +++ ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h  2007-05-20 23:15:59.000000000 +0200
> > > @@ -71,10 +71,10 @@
> > >       "copy   %5, %%r24                       \n\t"                   \
> > >       "ble    " LWS "(%%sr2, %%r0)            \n\t"                   \
> > >       "ldi    " LWS_CAS ", %%r20              \n\t"                   \
> > > +        "sub %%r0, %%r21, %%r21              \n\t"                   \
> > >       "cmpib,=,n " ASM_EAGAIN ",%%r21,0b      \n\t"                   \
> >
> > Hmmm, I think the original code was better since it keeps the sub
> > instruction outside the loop.  The cmpib instruction could be modified
> > to negate the ASM_EAGAIN.
> 
> The probability of the cmpib branching to 0b is directly proportional
> to the contention on the kernel lock selected by the address hash.
> Adding instructions to the loop is the equivalent of wasting time in
> userpace, so isn't it better to do as much in the loop as possible? I
> guess you waste memory bandwidth with the store.

In the linuxthread case, user spinlock code would typically spin a 
few times and then call nanosleep.  If this fails a few times, the code
calls sched_yield.  From a performance standpoint, I don't think it helps
to waste time in the loop itself.

On the otherhand, the atomic operations on the gateway page are short,
and processes on the gateway page are never supposed to be scheduled
off or sent signals.  So, I think a contended lock is only possible
with a SMP kernel.

> I hadn't considered this code would be an external API, but I guess it
> is... so these defines should probably go away and the constants
> merged into the code?

Yah, this just occurred to me.  It would be nice if the code could
use EAGAIN from errno.h but I can see that that's a bit tricky.
Possibly, a macro argument would work.

Dave
-- 
J. David Anglin                                  dave.anglin at nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)