Re: [PATCH -tip 2/3] sched/wake_q: Relax to acquire semantics

[Davidlohr Bueso]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/