Re: [PATCH 2/4] sched: Document Program-Order guarantees

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Nov 02, 2015 at 12:27:05PM -0800, Paul Turner wrote:
> I suspect this part might be more explicitly expressed by specifying
> the requirements that migration satisfies; then providing an example.
> This makes it easier for others to reason about the locks and saves
> worrying about whether the examples hit our 3 million sub-cases.
> 
> I'd also propose just dropping preemption from this part, we only need
> memory order to be correct on migration, whether it's scheduled or not
> [it also invites confusion with the wake-up case].
> 
> Something like:
> When any task 't' migrates, all activity on its prior cpu [c1] is
> guaranteed to be happens-before any subsequent execution on its new
> cpu [c2].  There are 3 components to enforcing this.
> 
> [c1]          1) Sched-out of t requires rq(c1)->lock
> [any cpu] 2) Any migration of t, by any cpu is required to synchronize
> on *both* rq(c1)->lock and rq(c2)->lock
> [c2]          3) Sched-in of t requires cq(c2)->lock
> 
> Transitivity guarantees that (2) orders after (1) and (3) after (2).
> Note that in some cases (e.g. active, or idle cpu) the balancing cpu
> in (2) may be c1 or c2.
> 
> [Follow example]

Make sense, I'll try and reword things like that.

Note that in don't actually need the strong transitivity here (RCsc),
weak transitivity (RCpc) is in fact sufficient.