From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753326AbbJTIh2 (ORCPT ); Tue, 20 Oct 2015 04:37:28 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:35912 "EHLO mail-wi0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752955AbbJTIh0 (ORCPT ); Tue, 20 Oct 2015 04:37:26 -0400 Date: Tue, 20 Oct 2015 10:37:21 +0200 From: Ingo Molnar To: Peter Zijlstra Cc: Catalin Marinas , "Paul E. McKenney" , Will Deacon , Linux Kernel Mailing List , Oleg Nesterov , Linus Torvalds , Andrew Morton Subject: Re: Q: schedule() and implied barriers on arm64 Message-ID: <20151020083720.GA14963@gmail.com> References: <20151016151830.GZ3816@twins.programming.kicks-ass.net> <20151016160422.GQ3910@linux.vnet.ibm.com> <20151016161608.GA3816@twins.programming.kicks-ass.net> <20151016190648.GC3816@twins.programming.kicks-ass.net> <20151019070604.GA17855@gmail.com> <20151019152108.GC11226@e104818-lin.cambridge.arm.com> <20151019162423.GP3816@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151019162423.GP3816@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Peter Zijlstra wrote: > On Mon, Oct 19, 2015 at 04:21:08PM +0100, Catalin Marinas wrote: > > On Mon, Oct 19, 2015 at 09:06:05AM +0200, Ingo Molnar wrote: > > > * Peter Zijlstra wrote: > > > > > > > In any case, its all moot now, since Paul no longer requires schedule() to imply > > > > a full barrier. > > > > > > > > [...] > > > > > > Nevertheless from a least-surprise POV it might be worth guaranteeing it, > > > because I bet there's tons of code that assumes that schedule() is a heavy > > > operation and it's such an easy mistake to make. Since we are so close to > > > having that guarantee, we might as well codify it? > > > > FWIW, the arm64 __switch_to() has a heavy barrier (DSB) but the reason for > > this was to cope with potentially interrupted cache or TLB maintenance (which > > require a DSB on the same CPU) and thread migration to another CPU. > > Right, but there's a path through schedule() that does not pass through > __switch_to(); when we pick the current task as the most eligible task and next > == prev. > > In that case there really only is the wmb, a spin lock, an atomic op and a spin > unlock (and a whole bunch of 'normal' code of course). Yeah, so my concern is that this is a rare race that might be 'surprising' for developers relying on various schedule() constructs. Especially as it's a full barrier on x86 (the most prominent SMP platform at the moment) there's a real danger of hard to debug bugs creeping to other architectures. So I think we should just do the small step of making it a full barrier everywhere - it's very close to it in any case, and it shouldn't really matter for performance. Agreed? Thanks, Ingo