Re: [PATCH 1/4] sched: Better document the try_to_wake_up() barriers

From: Byungchul Park
Date: Thu Dec 03 2015 - 19:09:40 EST


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 <paulmck@xxxxxxxxxxxxxxxxxx>
> Cc: Oleg Nesterov <oleg@xxxxxxxxxx>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
> ---
> 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 majordomo@xxxxxxxxxxxxxxx
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/