From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751835AbdH3SBk (ORCPT ); Wed, 30 Aug 2017 14:01:40 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:54587 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751318AbdH3SBi (ORCPT ); Wed, 30 Aug 2017 14:01:38 -0400 Date: Wed, 30 Aug 2017 11:01:31 -0700 From: "Paul E. McKenney" To: Mathieu Desnoyers Cc: Peter Zijlstra , linux-kernel , Boqun Feng , Andrew Hunter , maged michael , gromer , Avi Kivity , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Dave Watson , Andy Lutomirski , Will Deacon , Hans Boehm Subject: Re: [RFC PATCH 2/2] membarrier: provide register sync core cmd Reply-To: paulmck@linux.vnet.ibm.com References: <20170827195404.22171-1-mathieu.desnoyers@efficios.com> <20170827195404.22171-2-mathieu.desnoyers@efficios.com> <20170827203543.GH11320@linux.vnet.ibm.com> <1086910974.16837.1503867178642.JavaMail.zimbra@efficios.com> <20170827210009.GL11320@linux.vnet.ibm.com> <1573504622.16850.1503869994880.JavaMail.zimbra@efficios.com> <20170828174904.GW11320@linux.vnet.ibm.com> <949466399.31003.1504115633691.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <949466399.31003.1504115633691.JavaMail.zimbra@efficios.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17083018-0040-0000-0000-00000397CEBD X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007637; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000226; SDB=6.00909830; UDB=6.00456350; IPR=6.00690114; BA=6.00005562; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016930; XFM=3.00000015; UTC=2017-08-30 18:01:36 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17083018-0041-0000-0000-0000078C00A2 Message-Id: <20170830180131.GB11320@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-08-30_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708300273 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 30, 2017 at 05:53:53PM +0000, Mathieu Desnoyers wrote: > ----- On Aug 28, 2017, at 1:49 PM, Paul E. McKenney paulmck@linux.vnet.ibm.com wrote: > > > On Sun, Aug 27, 2017 at 09:39:54PM +0000, Mathieu Desnoyers wrote: > >> ----- On Aug 27, 2017, at 2:00 PM, Paul E. McKenney paulmck@linux.vnet.ibm.com > >> wrote: > >> > >> > On Sun, Aug 27, 2017 at 08:52:58PM +0000, Mathieu Desnoyers wrote: > >> >> ----- On Aug 27, 2017, at 1:35 PM, Paul E. McKenney paulmck@linux.vnet.ibm.com > >> >> wrote: > >> >> > >> >> > On Sun, Aug 27, 2017 at 12:54:04PM -0700, Mathieu Desnoyers wrote: > >> >> >> Add a new MEMBARRIER_CMD_REGISTER_SYNC_CORE command to the membarrier > >> >> >> system call. It allows processes to register their intent to have their > >> >> >> threads issue core serializing barriers in addition to memory barriers > >> >> >> whenever a membarrier command is performed. > >> >> >> > >> >> >> It is relevant for reclaim of JIT code, which requires to issue core > >> >> >> serializing barriers on all threads running on behalf of a process > >> >> >> after ensuring the old code is not visible anymore, before re-using > >> >> >> memory for new code. > >> >> >> > >> >> >> When a processes returns from a MEMBARRIER_CMD_REGISTER_SYNC_CORE > >> >> >> command, it is guaranteed that all following MEMBARRIER_CMD_SHARED and > >> >> >> MEMBARRIER_CMD_PRIVATE_EXPEDITED issue core serializing barriers, in > >> >> >> addition to the memory barriers, on all of its running threads. > >> >> > > >> >> > I have queued both of these for testing and review: > >> >> > > >> >> > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > >> >> > f54cf5123eb9 ("membarrier: Speed up single-threaded private cmd") > >> >> > 0d6eb99818da ("membarrier: Provide register sync core cmd") > >> >> > > >> >> > Could the people who asked for this please test it? The second commit > >> >> > is non-obvious enough to need some careful review and intensive testing > >> >> > before I can in good conscious pass it upstream. > >> >> > >> >> Thanks Paul! > >> >> > >> >> Can you pick up my v2 instead ? I added benchmarks in the changelog and > >> >> documented the new command in the membarrier public header. No changes > >> >> otherwise. > >> > > >> > It looks like 0day Test Robot also wants some additional header files. > >> > Could you please send me a v3 with its complaints addressed? > >> > >> I sent a separate patch implementing sync_core() on xtensa. It should > >> be applied before this patch. > > > > And it looks like we also need a sync_core() on every CPU family other > > than x86, which already has one. Do we want to make this capability > > depend on an ARCH_ kconfig option, or should we just bit the bullet and > > implement sync_core() everywhere? > > > > (I had to drop this commit due to downstream complaints. Left to myself, > > I would take the ARCH_ approach, then add it back in, but please let me > > know how you would like to proceed.) > > I plan to go with the ARCH_ approach indeed. Sounds good, looking forward to seeing it. ;-) Thanx, Paul