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=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 C1B61C2B9F4 for ; Thu, 17 Jun 2021 14:00:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2C2C861241 for ; Thu, 17 Jun 2021 14:00:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2C2C861241 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BBF276B006E; Thu, 17 Jun 2021 10:00:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B96706B0071; Thu, 17 Jun 2021 10:00:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A38856B0072; Thu, 17 Jun 2021 10:00:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0072.hostedemail.com [216.40.44.72]) by kanga.kvack.org (Postfix) with ESMTP id 7273E6B006E for ; Thu, 17 Jun 2021 10:00:55 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 08664824C423 for ; Thu, 17 Jun 2021 14:00:55 +0000 (UTC) X-FDA: 78263376870.32.D0490D8 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf07.hostedemail.com (Postfix) with ESMTP id 119A2A006BF9 for ; Thu, 17 Jun 2021 14:00:42 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 6883461241; Thu, 17 Jun 2021 14:00:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623938451; bh=Qld/pseRm0yfQ9yP2fU9GzvjQttVMbVMBgNd/24GmDw=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=T+f1Xp9tPYO3P+sYRvf+JXHpLZFTHGqXHDBQf5CnhnRXqaGVvFvsXOYTXF6+f7tPE mDzU39pXPO+nFKpDRpiu3Pge2Vto+9Vy1maAXnGqYAARJLgc6K4i5mSKTMNPwEAwIT 3gAq4cZFDHECozCVWkYKkPYX3jlOuFjwlxkGllmVOWojRzr2QU1l2AVek3RxFaJsG5 WVZBguBmrxBUKuVAz68m5N6tt/IEAiMsuIQFecLDD+s3iBkptE9XZACmrJLuPBLMge J4YiAHrIMyi+sUNqaTZkxsr6+8FYZBhq0N7bzKFLGhZ3B8O6jAfqYV6UrdTEGCNSts yY765r+FCchZw== Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailauth.nyi.internal (Postfix) with ESMTP id 7F8A227C0060; Thu, 17 Jun 2021 10:00:49 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute2.internal (MEProxy); Thu, 17 Jun 2021 10:00:49 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeefuddgjedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedftehn ugihucfnuhhtohhmihhrshhkihdfuceolhhuthhosehkvghrnhgvlhdrohhrgheqnecugg ftrfgrthhtvghrnhepvdelheejjeevhfdutdeggefftdejtdffgeevteehvdfgjeeiveei ueefveeuvdetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheprghnugihodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiudek heeifedvqddvieefudeiiedtkedqlhhuthhopeepkhgvrhhnvghlrdhorhhgsehlihhnuh igrdhluhhtohdruhhs X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A3BEC51C0061; Thu, 17 Jun 2021 10:00:47 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-526-gf020ecf851-fm-20210616.001-gf020ecf8 Mime-Version: 1.0 Message-Id: <33241b25-4d45-4278-a4e6-ec9c12b0e1f3@www.fastmail.com> In-Reply-To: <20210617135133.GA86101@C02TD0UTHF1T.local> References: <2142129092ff9aa00e600c42a26c4015b7f5ceec.1623813516.git.luto@kernel.org> <20210617103524.GA82133@C02TD0UTHF1T.local> <20210617112305.GK22278@shell.armlinux.org.uk> <20210617113349.GB82133@C02TD0UTHF1T.local> <394219d4-36a6-4e7f-a03c-8590551b099a@www.fastmail.com> <20210617135133.GA86101@C02TD0UTHF1T.local> Date: Thu, 17 Jun 2021 07:00:26 -0700 From: "Andy Lutomirski" To: "Mark Rutland" Cc: "Russell King (Oracle)" , "the arch/x86 maintainers" , "Dave Hansen" , "Linux Kernel Mailing List" , linux-mm@kvack.org, "Andrew Morton" , "Mathieu Desnoyers" , "Nicholas Piggin" , "Peter Zijlstra (Intel)" , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 7/8] membarrier: Remove arm (32) support for SYNC_CORE Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 119A2A006BF9 Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=T+f1Xp9t; spf=pass (imf07.hostedemail.com: domain of luto@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Stat-Signature: kkp6gizdfa3pp5f1zcwhumexmzbapysi X-HE-Tag: 1623938442-364303 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 Thu, Jun 17, 2021, at 6:51 AM, Mark Rutland wrote: > On Thu, Jun 17, 2021 at 06:41:41AM -0700, Andy Lutomirski wrote: > > In any event, I=E2=80=99m even more convinced that no new SYNC_CORE = arches > > should be added. We need a new API that just does the right thing.=20= >=20 > My intuition is the other way around, and that this is a gnereally > useful thing for architectures that require context synchronization. Except that you can't use it in a generic way. You have to know the spe= cific rules for your arch. >=20 > It's not clear to me what "the right thing" would mean specifically, a= nd > on architectures with userspace cache maintenance JITs can usually do > the most optimal maintenance, and only need help for the context > synchronization. >=20 This I simply don't believe -- I doubt that any sane architecture really= works like this. I wrote an email about it to Intel that apparently ge= nerated internal discussion but no results. Consider: mmap(some shared library, some previously unmapped address); this does no heavyweight synchronization, at least on x86. There is no = "serializing" instruction in the fast path, and it *works* despite anyth= ing the SDM may or may not say. We can and, IMO, should develop a sane way for user programs to install = instructions into VMAs, for security-conscious software to verify them (= by splitting the read and write sides?), and for their consumers to exec= ute them, without knowing any arch details. And I think this can be don= e with no IPIs except for possible TLB flushing when needed, at least on= most architectures. It would require a nontrivial amount of design wor= k, and it would not resemble sys_cacheflush() or SYNC_CORE. --Andy