From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: [RFC PATCH v3] membarrier: provide core serialization Date: Mon, 9 Oct 2017 09:32:53 +0100 Message-ID: <20171009083252.GA4693@arm.com> References: <20170901161007.2661-1-mathieu.desnoyers@efficios.com> <20170901162547.GA20313@arm.com> <1051991998.1330.1504285238477.JavaMail.zimbra@efficios.com> <20170901171048.GA20817@arm.com> <238182999.1493.1504291547065.JavaMail.zimbra@efficios.com> <20170918170129.GF11343@arm.com> <2063294388.33291.1507323476486.JavaMail.zimbra@efficios.com> <20171006210825.GA6524@worktop.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20171006210825.GA6524@worktop.programming.kicks-ass.net> Sender: linux-kernel-owner@vger.kernel.org To: Peter Zijlstra Cc: Mathieu Desnoyers , Hans Boehm , "Paul E. McKenney" , Boqun Feng , Andrew Hunter , maged michael , gromer , Avi Kivity , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Dave Watson , Andy Lutomirski , "Russell King, ARM Linux" , Greg Hackmann , David Sehr , linux-kernel , linux-arch , ralf@linux-mips.org List-Id: linux-arch.vger.kernel.org On Fri, Oct 06, 2017 at 11:08:25PM +0200, Peter Zijlstra wrote: > On Fri, Oct 06, 2017 at 08:57:56PM +0000, Mathieu Desnoyers wrote: > > Hi Hans, > > > > I'm currently making sure the > > MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED command makes its way into > > the 4.14 kernel before the end of the release candidates. Once that > > is done, I plan to post a patch adding a new MEMBARRIER_FLAG_SYNC_CORE > > flag for the 4.15 merge window. > > > > I have done a bit of research on the various architecture requirements > > for core serialization. Here are my findings so far about > > instructions providing core serialization on the main architectures > > supported by Linux. > > > > There are two places where we need it: in the interrupt handler for > > the membarrier IPI, and between scheduler execution (which can change > > the current "mm") and return to user-space. > > > > Please let me know if I missed anything. > > > > x86: iret, cpuid, wbinvd -> iret currently provides core serialization > > when going back to userspace and at the end of the IPI. There are > > plans to implement a return path without iret in the future, in which > > case I would need to issue an explicit "cpuid" instruction > > (sync_core()) in switch_mm() if the process is registered with > > MEMBARRIER_FLAG_SYNC_CORE. > > I would much prefer setting a TIF flag that forces the IRET path instead > of doing additional work in switch_mm(). > > > arm32: returning to user-space provides core serialization. Same at > > the end of membarrier IPI (to be confirmed). aarch64: ERET > > instruction used when returning to user-space provides core sync. Same > > at the end of membarrier IPI (to be confirmed). > > I thought Will already confirmed ERET did what we need, no? Yes. Will From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com ([217.140.101.70]:52848 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753981AbdJIIcu (ORCPT ); Mon, 9 Oct 2017 04:32:50 -0400 Date: Mon, 9 Oct 2017 09:32:53 +0100 From: Will Deacon Subject: Re: [RFC PATCH v3] membarrier: provide core serialization Message-ID: <20171009083252.GA4693@arm.com> References: <20170901161007.2661-1-mathieu.desnoyers@efficios.com> <20170901162547.GA20313@arm.com> <1051991998.1330.1504285238477.JavaMail.zimbra@efficios.com> <20170901171048.GA20817@arm.com> <238182999.1493.1504291547065.JavaMail.zimbra@efficios.com> <20170918170129.GF11343@arm.com> <2063294388.33291.1507323476486.JavaMail.zimbra@efficios.com> <20171006210825.GA6524@worktop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171006210825.GA6524@worktop.programming.kicks-ass.net> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Peter Zijlstra Cc: Mathieu Desnoyers , Hans Boehm , "Paul E. McKenney" , Boqun Feng , Andrew Hunter , maged michael , gromer , Avi Kivity , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Dave Watson , Andy Lutomirski , "Russell King, ARM Linux" , Greg Hackmann , David Sehr , linux-kernel , linux-arch , ralf@linux-mips.org Message-ID: <20171009083253.k4SRTSSOwkUeztEEya7ZzayadoVq9fDfUD9nY0hkU_k@z> On Fri, Oct 06, 2017 at 11:08:25PM +0200, Peter Zijlstra wrote: > On Fri, Oct 06, 2017 at 08:57:56PM +0000, Mathieu Desnoyers wrote: > > Hi Hans, > > > > I'm currently making sure the > > MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED command makes its way into > > the 4.14 kernel before the end of the release candidates. Once that > > is done, I plan to post a patch adding a new MEMBARRIER_FLAG_SYNC_CORE > > flag for the 4.15 merge window. > > > > I have done a bit of research on the various architecture requirements > > for core serialization. Here are my findings so far about > > instructions providing core serialization on the main architectures > > supported by Linux. > > > > There are two places where we need it: in the interrupt handler for > > the membarrier IPI, and between scheduler execution (which can change > > the current "mm") and return to user-space. > > > > Please let me know if I missed anything. > > > > x86: iret, cpuid, wbinvd -> iret currently provides core serialization > > when going back to userspace and at the end of the IPI. There are > > plans to implement a return path without iret in the future, in which > > case I would need to issue an explicit "cpuid" instruction > > (sync_core()) in switch_mm() if the process is registered with > > MEMBARRIER_FLAG_SYNC_CORE. > > I would much prefer setting a TIF flag that forces the IRET path instead > of doing additional work in switch_mm(). > > > arm32: returning to user-space provides core serialization. Same at > > the end of membarrier IPI (to be confirmed). aarch64: ERET > > instruction used when returning to user-space provides core sync. Same > > at the end of membarrier IPI (to be confirmed). > > I thought Will already confirmed ERET did what we need, no? Yes. Will