Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp227081pxj; Wed, 16 Jun 2021 00:39:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyjF4Nlhx9xZbyN2DIb3tkC75G0853+evh8722x3pq/1G/22Jc/ADsMMw4YO/rkX3IPtqzH X-Received: by 2002:a05:6402:35cc:: with SMTP id z12mr2573335edc.45.1623829172766; Wed, 16 Jun 2021 00:39:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623829172; cv=none; d=google.com; s=arc-20160816; b=DS0eMmJNjkXBqCuWQpDUn+8Zk+tUgVsdmi5YjCqBB5E/WWeFPflb365KLgjRxyGikz u7/c6Uh2PHA9pQvEakcBftMSKkehq+Iu1ClJjK3ZJwpLDhmIwb+Qigv900DLHMJb2pM+ q77v9kEIgAc13HgM/Gk2KiVSelYiu62QtUbshj0yNJ6dWUP8VlObE0CqmVKUDVE+zkpv EVG3DncYoxGcyby45bEliZUUYXc4cTcSv3Z22SvjFbVmjklnxuxF8w/WUpox+rPZLkoQ fzK72nsi9GiUZl6rYHPs1ObvRyHsBuzLmc5JOiMLDjBjoDW+hqZWTkRSL0drrwuueEhx gBBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=tBkdyBvssbB26l8OwNvWpFnMG7gfD6M7+NbkQD+lW/0=; b=sMB07i2vTrAsCOHMgaXfv8ysOTQfYJKYmmuEHag9gSgk/wKJsOwpfZBQ9xowbeRQEd fLLogV1GnMW7hZp51O69+GqxapLdmmYJAwMN2JElcJ10Xj8QnWAI3PTIEG6Kv3uBWmX+ Ym/sl04YYqJ+CdfxZoP5EwdANu5LkviFEFXb+SX9fFhcQgWpzA3BexFKGQuhkU5q4fgB glkRaOHIGIAG2GoWCum4gUvwh+agVcS4X7jCxqoBUVDkyNHm3bmMHy45RxM1S+AgE2DO GsNvghwf5BcoYinnlNQtUDy0JrZLpAWV/912XVMOvZ4SEHYA4H8ZW7segSEnuwOnSgzM S3dA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=desiato.20200630 header.b=j7HcOUOW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bt10si1554256ejb.390.2021.06.16.00.39.10; Wed, 16 Jun 2021 00:39:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=desiato.20200630 header.b=j7HcOUOW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231892AbhFPHhw (ORCPT + 99 others); Wed, 16 Jun 2021 03:37:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231293AbhFPHhw (ORCPT ); Wed, 16 Jun 2021 03:37:52 -0400 Received: from desiato.infradead.org (desiato.infradead.org [IPv6:2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 08D9FC061574 for ; Wed, 16 Jun 2021 00:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=tBkdyBvssbB26l8OwNvWpFnMG7gfD6M7+NbkQD+lW/0=; b=j7HcOUOWaM7jy1+syfaU8rzcPO FXmfQe8ZR8ALTJN/RdEBWi6Jwl7vo9HsOwTN4k3SpOYDIbtPpDejXQsVQWQNUaUSzMLJxROZ1wteA 6sggWbqz9tH730Wu7lvQFS7zXBw/2ZJT9CTra1Jvab5zh2K0EDuaOVLfIBfLzd8tLs7iw+gT+6c+r qDNWDnanmkiFSM9GfzGHPmFIXQa+KTnwSgaQUxULjpIuDsDnVXeESeMlVIZiIMi3uPsSzV6J1ScKf KaWhmOG6KkpLXW6hK1V2FwoY7WtohLs2DeJvatMrSl8d9hZKC8pBdxzEA1BSbf77ViwcLszMC6e4y rewIhSdA==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1ltQ58-008GOH-EB; Wed, 16 Jun 2021 07:35:33 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 9DF433001E3; Wed, 16 Jun 2021 09:35:32 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 867C020277F84; Wed, 16 Jun 2021 09:35:32 +0200 (CEST) Date: Wed, 16 Jun 2021 09:35:32 +0200 From: Peter Zijlstra To: Nicholas Piggin Cc: Andy Lutomirski , x86@kernel.org, Andrew Morton , Dave Hansen , LKML , linux-mm@kvack.org, Mathieu Desnoyers Subject: Re: [PATCH 4/8] membarrier: Make the post-switch-mm barrier explicit Message-ID: References: <1623816595.myt8wbkcar.astroid@bobo.none> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1623816595.myt8wbkcar.astroid@bobo.none> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 16, 2021 at 02:19:49PM +1000, Nicholas Piggin wrote: > Excerpts from Andy Lutomirski's message of June 16, 2021 1:21 pm: > > membarrier() needs a barrier after any CPU changes mm. There is currently > > a comment explaining why this barrier probably exists in all cases. This > > is very fragile -- any change to the relevant parts of the scheduler > > might get rid of these barriers, and it's not really clear to me that > > the barrier actually exists in all necessary cases. > > The comments and barriers in the mmdrop() hunks? I don't see what is > fragile or maybe-buggy about this. The barrier definitely exists. > > And any change can change anything, that doesn't make it fragile. My > lazy tlb refcounting change avoids the mmdrop in some cases, but it > replaces it with smp_mb for example. I'm with Nick again, on this. You're adding extra barriers for no discernible reason, that's not generally encouraged, seeing how extra barriers is extra slow. Both mmdrop() itself, as well as the callsite have comments saying how membarrier relies on the implied barrier, what's fragile about that?