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