Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1229605

Re: [PATCH] Documentation: Remove misleading examples of the barriers in wake_*()

From Oleg Nesterov <oleg@redhat.com>
Newsgroups linux.kernel
Subject Re: [PATCH] Documentation: Remove misleading examples of the barriers in wake_*()
Date 2015-09-21 19:50 +0200
Message-ID <qbdnZ-5do-35@gated-at.bofh.it> (permalink)
References (2 earlier) <q6ZCW-4Mz-11@gated-at.bofh.it> <q7eiC-eo-11@gated-at.bofh.it> <q9H6P-4rU-27@gated-at.bofh.it> <q9KR3-1yz-5@gated-at.bofh.it> <q9XOi-3rU-19@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 09/18, Peter Zijlstra wrote:
>
> the text is correct, right?

Yes, it looks good to me and helpful.

But damn. I forgot why exactly try_to_wake_up() needs rmb() after
->on_cpu check... It looks reasonable in any case, but I do not
see any strong reason immediately.

Say,

	p->sched_contributes_to_load = !!task_contributes_to_load(p);
	p->state = TASK_WAKING;

we can actually do this before "while (p->on_cpu)", afaics. However
we must not do this before the previous p->on_rq check.

So perhaps this rmb() helps to ensure task_contributes_to_load() can't
happen before p->on_rq check...

As for "p->state = TASK_WAKING" we have the control dependency in both
cases. But the modern fashion suggests to use _CTRL(). Although cpu_relax()
should imply barrier(), but afaik this is not documented.

In short, I got lost ;) Now I don't even understand why we do not need
another rmb() between p->on_rq and p->on_cpu. Suppose a thread T does

	set_current_state(...);
	schedule();

it can be preempted in between, after that we have "on_rq && !on_cpu".
Then it gets CPU again and calls schedule() which clears on_rq.

What guarantees that if ttwu() sees on_rq == 0 cleared by schedule()
then it can _not_ still see the old value of on_cpu == 0?

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] Documentation: Remove misleading examples of the barriers in wake_*() Boqun Feng <boqun.feng@gmail.com> - 2015-09-08 03:20 +0200
  Re: [PATCH] Documentation: Remove misleading examples of the  barriers in wake_*() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-09-09 21:30 +0200
    Re: [PATCH] Documentation: Remove misleading examples of the  barriers in wake_*() Boqun Feng <boqun.feng@gmail.com> - 2015-09-10 04:20 +0200
      Re: [PATCH] Documentation: Remove misleading examples of the  barriers in wake_*() Oleg Nesterov <oleg@redhat.com> - 2015-09-10 20:00 +0200
        Re: [PATCH] Documentation: Remove misleading examples of the  barriers in wake_*() Boqun Feng <boqun.feng@gmail.com> - 2015-09-11 19:10 +0200
        Re: [PATCH] Documentation: Remove misleading examples of the  barriers in wake_*() Peter Zijlstra <peterz@infradead.org> - 2015-09-17 15:10 +0200
          Re: [PATCH] Documentation: Remove misleading examples of the  barriers in wake_*() Oleg Nesterov <oleg@redhat.com> - 2015-09-17 19:10 +0200
            Re: [PATCH] Documentation: Remove misleading examples of the  barriers in wake_*() Peter Zijlstra <peterz@infradead.org> - 2015-09-18 09:00 +0200
              Re: [PATCH] Documentation: Remove misleading examples of the  barriers in wake_*() Oleg Nesterov <oleg@redhat.com> - 2015-09-21 19:50 +0200
          Re: [PATCH] Documentation: Remove misleading examples of the  barriers in wake_*() Boqun Feng <boqun.feng@gmail.com> - 2015-09-24 15:30 +0200

csiph-web