Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751711AbdITQCj (ORCPT ); Wed, 20 Sep 2017 12:02:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:55034 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751550AbdITQCh (ORCPT ); Wed, 20 Sep 2017 12:02:37 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A157822A9A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org X-Google-Smtp-Source: AOwi7QBrhU5TaJx89tqAj966x4iEvg5JCFipYwziZPtwCKCUW1STDth9OrXWSJCHpwd+gHBMsyrm3jnDxLZ7J2mlQGw= MIME-Version: 1.0 In-Reply-To: <20170917223608.GA14577@linux.vnet.ibm.com> References: <20170917223608.GA14577@linux.vnet.ibm.com> From: Andy Lutomirski Date: Wed, 20 Sep 2017 09:02:15 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Rough notes from sys_membarrier() lightning BoF To: "Paul E. McKenney" Cc: Peter Zijlstra , Mathieu Desnoyers , Will Deacon , Alan Stern , Andrew Lutomirski , Michael Ellerman , "linux-kernel@vger.kernel.org" , linux-arch , Dave Watson , Maged Michael Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1748 Lines: 36 On Sun, Sep 17, 2017 at 3:36 PM, Paul E. McKenney wrote: > Hello! > > Rough notes from our discussion last Thursday. Please reply to the > group with any needed elaborations or corrections. > > Adding Andy and Michael on CC since this most closely affects their > architectures. Also adding Dave Watson and Maged Michael because > the preferred approach requires that processes wanting to use the > lightweight sys_membarrier() do a registration step. Not to be too much of a curmudgeon, but I think that there should be a real implementation of the isync membarrier before this get merged. This series purports to solve two problems, ppc barriers and x86 exit-without-isync, but it's very hard to evaluate whether it actually solves the latter problem given the complete lack of x86 or isync code in the current RFC. It still seems to me that you won't get any particular advantage for using this registration mechanism on x86 even when you implement isync. Unless I've misunderstood, the only real issue on x86 is that you need a helper like arch_force_isync_before_usermode(), and that helper doesn't presently exist. That means that this whole patchset is standing on very dangerous ground: you'll end up with an efficient implementation that works just fine without even requesting registration on every architecture except ppc. That way lies userspace bugs. Also, can you elaborate on the PPC issue? PPC appears to track mm_cpumask more or less just like x86. Is the issue just that this tracking has no implied barriers? If so, how does TLB flush on ppc work? It really does seem impressive to me that an architecture can efficiently support munmap() but not an expedited private membarrier. --Andy