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. -- 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/
