From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752943AbbKBUex (ORCPT ); Mon, 2 Nov 2015 15:34:53 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:42493 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752823AbbKBUev (ORCPT ); Mon, 2 Nov 2015 15:34:51 -0500 Date: Mon, 2 Nov 2015 21:34:42 +0100 From: Peter Zijlstra To: Paul Turner Cc: Ingo Molnar , Oleg Nesterov , LKML , Paul McKenney , boqun.feng@gmail.com, Jonathan Corbet , mhocko@kernel.org, dhowells@redhat.com, Linus Torvalds , will.deacon@arm.com Subject: Re: [PATCH 2/4] sched: Document Program-Order guarantees Message-ID: <20151102203442.GW17308@twins.programming.kicks-ass.net> References: <20151102132901.157178466@infradead.org> <20151102134940.883198067@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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.