On Mon, 14 Sep 2015, Peter Zijlstra wrote:
On Mon, Sep 14, 2015 at 12:37:23AM -0700, Davidlohr Bueso wrote:
/*
+ * Atomically grab the task. If ->wake_q is non-nil (failed cmpxchg)
+ * then the task is already queued (by us or someone else) and will
+ * get the wakeup due to that.
*
+ * Use acquire semantics to add the next pointer, which pairs with the
+ * write barrier implied by the wakeup in wake_up_list().
*/
+ if (cmpxchg_acquire(&node->next, NULL, WAKE_Q_TAIL))
return;
get_task_struct(task);
I'm not seeing a _why_ on the acquire semantics. Not saying the patch is
wrong, just saying I want words on why acquire is correct.
Well, I was just taking advantage of removing the upper barrier. Considering
that the formal semantics, you are right that we need not actual acquire per-se
(ie for node->next) but instead merely ensure a barrier in wake_q_add(). This is
kind of why I had hinted of going full _relaxed(). We could also rephrase the
comment, something like:
* Use ACQUIRE semantics to add the next pointer, such that
* wake_q_add() implies a full barrier. This pairs with the
* write barrier implied by the wakeup in wake_up_list().
*/
What do you think?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
