On Mon, Nov 02, 2015 at 02:29:02PM +0100, Peter Zijlstra wrote: > Explain how the control dependency and smp_rmb() end up providing > ACQUIRE semantics and pair with smp_store_release() in > finish_lock_switch(). > > Cc: Paul E. McKenney <paul...@linux.vnet.ibm.com> > Cc: Oleg Nesterov <o...@redhat.com> > Signed-off-by: Peter Zijlstra (Intel) <pet...@infradead.org> > --- > kernel/sched/core.c | 8 +++++++- > kernel/sched/sched.h | 3 +++ > 2 files changed, 10 insertions(+), 1 deletion(-) > > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -1947,7 +1947,13 @@ try_to_wake_up(struct task_struct *p, un > while (p->on_cpu) > cpu_relax(); > /* > - * Pairs with the smp_wmb() in finish_lock_switch(). > + * Combined with the control dependency above, we have an effective > + * smp_load_acquire() without the need for full barriers. > + * > + * Pairs with the smp_store_release() in finish_lock_switch(). > + * > + * This ensures that tasks getting woken will be fully ordered against > + * their previous state and preserve Program Order. > */ > smp_rmb();
Hello, I am not sure, but just curious.. I thought it's good enough to use a kind of dependancy barrier such as smp_read_barrier_depends() instead of smp_rmb() here unless something e.g. compiler breaks the control dependacy. Right? > > --- a/kernel/sched/sched.h > +++ b/kernel/sched/sched.h > @@ -1073,6 +1073,9 @@ static inline void finish_lock_switch(st > * We must ensure this doesn't happen until the switch is completely > * finished. > * > + * In particular, the load of prev->state in finish_task_switch() must > + * happen before this. > + * > * Pairs with the control dependency and rmb in try_to_wake_up(). > */ > smp_store_release(&prev->on_cpu, 0); > > > -- > 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/ -- 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/
