> On Mon, Jan 24, 2011 at 01:56:53PM -0800, Jeremy Fitzhardinge wrote: For some reason, I seem to be missing emails from your id/domain and hence had missed this completely! > > * bits. However, we need to be careful about this because someone > > * may just be entering as we leave, and enter the slowpath. > > */ > > -void __ticket_unlock_release_slowpath(struct arch_spinlock *lock) > > +void __ticket_unlock_slowpath(struct arch_spinlock *lock) > > { > > struct arch_spinlock old, new; > > > > BUILD_BUG_ON(((__ticket_t)NR_CPUS) != NR_CPUS); > > > > old = ACCESS_ONCE(*lock); > > - > > new = old; > > - new.tickets.head += TICKET_LOCK_INC; > > > > /* Clear the slowpath flag */ > > new.tickets.tail &= ~TICKET_SLOWPATH_FLAG; > > + if (new.tickets.head == new.tickets.tail) > > + cmpxchg(&lock->head_tail, old.head_tail, new.head_tail); > > > > - /* > > - * If there's currently people waiting or someone snuck in > > - * since we read the lock above, then do a normal unlock and > > - * kick. If we managed to unlock with no queued waiters, then > > - * we can clear the slowpath flag. > > - */ > > - if (new.tickets.head != new.tickets.tail || > > - cmpxchg(&lock->head_tail, > > - old.head_tail, new.head_tail) != old.head_tail) { > > - /* still people waiting */ > > - __ticket_unlock_release(lock); > > - } > > - > > + /* Wake up an appropriate waiter */ > > __ticket_unlock_kick(lock, new.tickets.head); > > Does the __ticket_unlock_kick need to be unconditional? I recall having tried optimizing it to be conditional, something along these lines: if (new.ticket.head == new.tickets.tail) { cmpxchg(); } else { __ticket_unlock_kick(lock, new.tickets.head); } but it didn't work for some reason. I left the call unconditional as was the case previously based on that experiment. - vatsa _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization