lkml.org 
[lkml]   [2013]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 tip/core/locking 6/7] locking: Add an smp_mb__after_unlock_lock() for UNLOCK+LOCK barrier
On Tue, Dec 10, 2013 at 06:04:04PM +0100, Oleg Nesterov wrote:
> On 12/09, Paul E. McKenney wrote:
> >
> > This commit therefore adds a smp_mb__after_unlock_lock(), which may be
> > placed after a LOCK primitive to restore the full-memory-barrier semantic.
> > All definitions are currently no-ops, but will be upgraded for some
> > architectures when queued locks arrive.
>
> I am wondering, perhaps smp_mb__after_unlock() makes more sense?
>
> Note that it already has the potential user:
>
> --- x/kernel/sched/wait.c
> +++ x/kernel/sched/wait.c
> @@ -176,8 +176,9 @@ prepare_to_wait(wait_queue_head_t *q, wa
> spin_lock_irqsave(&q->lock, flags);
> if (list_empty(&wait->task_list))
> __add_wait_queue(q, wait);
> - set_current_state(state);
> + __set_current_state(state);
> spin_unlock_irqrestore(&q->lock, flags);
> + smp_mb__after_unlock();
> }
> EXPORT_SYMBOL(prepare_to_wait);
>
> @@ -190,8 +191,9 @@ prepare_to_wait_exclusive(wait_queue_hea
> spin_lock_irqsave(&q->lock, flags);
> if (list_empty(&wait->task_list))
> __add_wait_queue_tail(q, wait);
> - set_current_state(state);
> + __set_current_state(state);
> spin_unlock_irqrestore(&q->lock, flags);
> + smp_mb__after_unlock();
> }
> EXPORT_SYMBOL(prepare_to_wait_exclusive);
>
>
> Assuming it can also be used "later", after another LOCK, like in
> your example in 5/7.

I am fine either way. But there was an objection to tying this to the
unlock because it costs more on many architectures than tying this to
the lock.

But if you are saying "in addition to" rather than "instead of" that
would be a different conversation.

Thanx, Paul



\
 
 \ /
  Last update: 2013-12-10 19:01    [W:0.135 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site