On Mon, 2014-02-10 at 20:58 +0100, Peter Zijlstra wrote: > +unqueue: > + /* > + * Step - A -- stabilize @prev > + * > + * Undo our @prev->next assignment; this will make @prev's > + * unlock()/unqueue() wait for a next pointer since @lock points to us > + * (or later). > + */ > + > + for (;;) { > + if (prev->next == node && > + cmpxchg(&prev->next, node, NULL) == node) > + break; > + > + /* > + * We can only fail the cmpxchg() racing against an unlock(), > + * in which case we should observe @node->locked becomming > + * true. > + */ > + if (smp_load_acquire(&node->locked)) > + return true; > + > + /* > + * Or we race against a concurrent unqueue()'s step-B, in which > + * case its step-C will write us a new @node->prev pointer. > + */ > + prev = ACCESS_ONCE(node->prev);
Should we also add an arch_mutex_cpu_relax() to this loop? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/