From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1CC4C48BE6 for ; Wed, 16 Jun 2021 07:35:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9527B6044F for ; Wed, 16 Jun 2021 07:35:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9527B6044F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 19C836B006C; Wed, 16 Jun 2021 03:35:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 14CDA6B006E; Wed, 16 Jun 2021 03:35:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F14406B0070; Wed, 16 Jun 2021 03:35:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0162.hostedemail.com [216.40.44.162]) by kanga.kvack.org (Postfix) with ESMTP id BDA4A6B006C for ; Wed, 16 Jun 2021 03:35:45 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 68ACA83EB for ; Wed, 16 Jun 2021 07:35:45 +0000 (UTC) X-FDA: 78258777450.27.2B44909 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) by imf26.hostedemail.com (Postfix) with ESMTP id 0EBA24202A03 for ; Wed, 16 Jun 2021 07:35:38 +0000 (UTC) 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> Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b=j7HcOUOW; spf=none (imf26.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=peterz@infradead.org; dmarc=none X-Stat-Signature: a9ejwz7qmd9s3hm3kc7xopj1f4fa35az X-Rspamd-Queue-Id: 0EBA24202A03 X-Rspamd-Server: rspam06 X-HE-Tag: 1623828938-769506 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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?