From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751609AbdH3Oqu (ORCPT ); Wed, 30 Aug 2017 10:46:50 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:58057 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751552AbdH3Oqt (ORCPT ); Wed, 30 Aug 2017 10:46:49 -0400 Date: Wed, 30 Aug 2017 07:46:41 -0700 From: "Paul E. McKenney" To: Andy Lutomirski Cc: Mathieu Desnoyers , 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: [PATCH v2] membarrier: provide register sync core cmd Reply-To: paulmck@linux.vnet.ibm.com References: <20170827205035.25620-1-mathieu.desnoyers@efficios.com> <1463521395.16945.1503889546934.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17083014-0040-0000-0000-00000397BB04 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007636; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000226; SDB=6.00909765; UDB=6.00456311; IPR=6.00690049; BA=6.00005561; 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 14:46:46 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17083014-0041-0000-0000-0000078BECD1 Message-Id: <20170830144641.GV11320@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-08-30_06:,, 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-1708300222 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 29, 2017 at 10:01:56PM -0700, Andy Lutomirski wrote: > > On Aug 27, 2017, at 8:05 PM, Mathieu Desnoyers wrote: > > > > ----- On Aug 27, 2017, at 3:53 PM, Andy Lutomirski luto@amacapital.net wrote: > > > >>> On Aug 27, 2017, at 1:50 PM, 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. > >>> > >> > >> Why is this stateful? That is, why not just have a new membarrier command to > >> sync every thread's icache? > > > > If we'd do it on every CPU icache, it would be as trivial as you say. The > > concern here is sending IPIs only to CPUs running threads that belong to the > > same process, so we don't disturb unrelated processes. > > > > If we could just grab each CPU's runqueue lock, it would be fairly simple > > to do. But we want to avoid hitting each runqueue with exclusive atomic > > access associated with grabbing the lock. (cache-line bouncing) > > Hmm. Are there really arches where there is no clean implementation > without this hacker? It seems rather unfortunate that munmap() can be > done efficiently but this barrier can't be. > > At the very least, could there be a register command *and* a special > sync command? I dislike the idea that the sync command does something > different depending on some other state. Even better (IMO) would be a > design where you ask for an isync and, if the arch can do it > efficiently (x86), you get an efficient isync and, if the arch can't > (arm64?) you take all the rq locks? In some cases I suspect that IPIs might be required. Regardless of that, we might well need to provide a way for architectures to do special things. But I must defer to Mathieu on this. Thanx, Paul