spinlocks

Dave Engebretsen engebret at vnet.ibm.com
Thu Jan 8 02:09:32 EST 2004


Just getting caught up after break -

Anton Blanchard wrote:
> Hi,
>
> We really have to get the new spinlocks beaten into shape...
>
> 3. Separate spinlocks for iseries and pseries where most of it is
> duplicated.

I do not follow this point -

> As an aside, can someone explain why we reread the lock holder:
>
>         lwsync                          # if odd, give up cycles\n\
>         ldx             %1,0,%2         # reverify the lock holder\n\
>         cmpd            %0,%1\n\
>         bne             1b              # new holder so restart\n\
>
> Wont there be a race regardless of whether this code is there?

It is a tricky case, but the sequence is required.  Here is the situation:

Proc A holds the lock
Proc B sees proc A as the holder, then gets preempted
Proc A drops the lock, then cedes for a long time
Proc B reads proc A's yield count, which is valid (odd)
Proc B confers to proc A, but does not wake up until after A is dispatched.

The lwsync + reread ensures this cannot occur.

> 1. Recognise that once we are in SPLPAR mode, all performance bets are
> off and we can burn more cycles. If we are calling into the hypervisor,
> the path length there is going to dwarf us so why optimise for it?

While I agree performance is less important in SPLPAR mode than
dedicated, it is still important.  The vast majority of customers on
iSeries run in this mode.

Dave.

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





More information about the Linuxppc64-dev mailing list