On Mon, Sep 14, 2015 at 12:37:23AM -0700, Davidlohr Bueso wrote: > The barrier parings for wake-queues are very straightforward, and thus > we can ease the barrier requirements, for archs that support it, for > wake_q_add by relying on acquire semantics. As such, (i) we keep the > pairing structure/logic and (ii) users, such as mqueues, can continue to > rely on a full barrier after the successful [Rmw].
> Signed-off-by: Davidlohr Bueso <[email protected]> > --- > kernel/sched/core.c | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index 6ab415a..7567603 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -523,14 +523,14 @@ void wake_q_add(struct wake_q_head *head, struct > task_struct *task) > struct wake_q_node *node = &task->wake_q; > > /* > + * 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. -- 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/
