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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40DBECEBF62 for ; Fri, 27 Sep 2024 00:02:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6EF526B009C; Thu, 26 Sep 2024 20:02:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 69E9C6B009E; Thu, 26 Sep 2024 20:02:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 518EB6B009F; Thu, 26 Sep 2024 20:02:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 30DB66B009C for ; Thu, 26 Sep 2024 20:02:26 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7E87A16078F for ; Fri, 27 Sep 2024 00:02:25 +0000 (UTC) X-FDA: 82608566250.10.8E1EB68 Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) by imf16.hostedemail.com (Postfix) with ESMTP id 34EC4180015 for ; Fri, 27 Sep 2024 00:02:23 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=nJBb49qj; spf=pass (imf16.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.222.174 as permitted sender) smtp.mailfrom=boqun.feng@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727395221; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=YjCSmMibXXEPpnXZCTdjE8rV5Ekv91uy3bvJiKflnq8=; b=4/uni47EYujLeZF/1XMmQGEXnmo43SmaJJNxnUIR/UY0/AWkDYIBnQ9ab45vKTX2IS87EA s4dehY72pkhPxeU2fiNvf8M01hDWiL4MESs0cr5TwG4fsF56gJm+YUaZttq1x09bfvjW19 IrnsEnpivil0PHKemUvQJSXGvw+9HiM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727395221; a=rsa-sha256; cv=none; b=yxr3Ly1dzcL7CipSIyLg7N+8qDyyaWlmQ5jiFROhxgAk8NvEBAh71B55cVwZLQG/bpsd2h em6B8d5l8zs3YzI+sVtf3FAJz79lABAsaVEjpvrH7E1Gwg548tc4HN+i25fFJRxGAjDHkC nRn6L7dW7h14Sm71rEr7ElGuL8jKVws= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=nJBb49qj; spf=pass (imf16.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.222.174 as permitted sender) smtp.mailfrom=boqun.feng@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qk1-f174.google.com with SMTP id af79cd13be357-7a7f8b0b7d0so89974085a.2 for ; Thu, 26 Sep 2024 17:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727395342; x=1728000142; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=YjCSmMibXXEPpnXZCTdjE8rV5Ekv91uy3bvJiKflnq8=; b=nJBb49qj45es6HyeR6r1gGCrPzHvVBUBxxw5tDvelGhnjqpciFICZeDCTzcxlQfhX8 4RAjqTmhFLSHYDv5H11XgL31jFluMhwVXv2v1BjiEjMHYq4sEie7Hrzz5iXm5Vfmp3li YTR9UIWaIpzKomCvJXDHkcfTT9qubJV7+6LcsElkloKj2JmLJaA/x7w54HCibGbJCVnz ao0qSgkFoBApEk/AN7tJmuOob2WMNzRMhZNXCkdD0LvVG9B8jEd8IU6Htu9OxwkI7aWP VaRN3uSi6g0VyExsm54TYqMkzdUgr75zAXZq1pfBoRe54YTUyWNhsVwDypqKARZi1KU7 vEZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727395342; x=1728000142; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YjCSmMibXXEPpnXZCTdjE8rV5Ekv91uy3bvJiKflnq8=; b=rUJx/oXGjSfK1+tlvw86zeWzVtrhYxaIuBzvNy3joQObhVGfTyXKSO7aa5m3WeQ1JN H3VNh9F6ApdFtlR73fZ0pQN0zQ3S4byWNqsYSxUCbQU1Sm4qXG51dNls9pFRQGim1GZM 4BOAAKZRq/+EZ9yI74KyJG2+bTvlk70yxQrc5SA9kQTs2GNaAC8CZVHfXzVJIyMKzs0O VtUd3W2Ay89In8AA/rZLLI1ZD/Mwbt02Dtkh3pFjTqUNWOO9hkWwYvfc6JgyKPXE/lKW sV4nmarMyLihfWBlgKri3q0tJ2i37keYTzZaJz2wf+g4KkTOYqup2Pdx/AfjhrFpdPMb KS/Q== X-Forwarded-Encrypted: i=1; AJvYcCWch6Y/BgNW8HrPLoWjl/6mioqUFO9UGT3xyX2rKpJXY9VpzIqrAr5D9KYWW63t1+7wvE1BhnO0Sw==@kvack.org X-Gm-Message-State: AOJu0YygP618dIs4nn7q+77bnQxYkUVdidywAyhpyVsglzGE7i7BqUvN tE4qElaNMLk8b8znHZHz9pkA0SctZXtvk2JuQb137bk//ndY5Y/4 X-Google-Smtp-Source: AGHT+IETPGhDSd2dPTaUTe/MpX7CvYID59u5rcY/0DoOFj9RnHuwMiq3GVfzLGUfcMWFWNdyAVZ8ng== X-Received: by 2002:a05:620a:d81:b0:7a9:b3eb:9ca1 with SMTP id af79cd13be357-7ae37852a69mr174950285a.28.1727395340967; Thu, 26 Sep 2024 17:02:20 -0700 (PDT) Received: from fauth-a2-smtp.messagingengine.com (fauth-a2-smtp.messagingengine.com. [103.168.172.201]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7ae377ecc4dsm36520085a.70.2024.09.26.17.02.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Sep 2024 17:02:20 -0700 (PDT) Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfauth.phl.internal (Postfix) with ESMTP id 8A96C1200043; Thu, 26 Sep 2024 20:02:19 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Thu, 26 Sep 2024 20:02:19 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvddtkedgvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvden ucfhrhhomhepuehoqhhunhcuhfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrd gtohhmqeenucggtffrrghtthgvrhhnpeehudfgudffffetuedtvdehueevledvhfelleei vedtgeeuhfegueevieduffeivdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpegsohhquhhnodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhi thihqdeiledvgeehtdeigedqudejjeekheehhedvqdgsohhquhhnrdhfvghngheppehgmh grihhlrdgtohhmsehfihigmhgvrdhnrghmvgdpnhgspghrtghpthhtohepvdejpdhmohgu vgepshhmthhpohhuthdprhgtphhtthhopehtohhrvhgrlhgusheslhhinhhugidqfhhouh hnuggrthhiohhnrdhorhhgpdhrtghpthhtohepjhhonhgrshdrohgsvghrhhgruhhsvghr sehhuhgrfigvihgtlhhouhgurdgtohhmpdhrtghpthhtohepmhgrthhhihgvuhdruggvsh hnohihvghrshesvghffhhitghiohhsrdgtohhmpdhrtghpthhtoheplhhinhhugidqkhgv rhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprhgtuhesvhhgvg hrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhmmheskhhvrggtkhdr ohhrghdprhgtphhtthhopehlkhhmmheslhhishhtshdrlhhinhhugidruggvvhdprhgtph htthhopehprghulhhmtghksehkvghrnhgvlhdrohhrghdprhgtphhtthhopehfrhgvuggv rhhitgeskhgvrhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 26 Sep 2024 20:02:18 -0400 (EDT) Date: Thu, 26 Sep 2024 17:01:31 -0700 From: Boqun Feng To: Linus Torvalds Cc: Jonas Oberhauser , Mathieu Desnoyers , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-mm@kvack.org, lkmm@lists.linux.dev, "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Uladzislau Rezki , Steven Rostedt , Lai Jiangshan , Zqiang , Peter Zijlstra , Ingo Molnar , Will Deacon , Waiman Long , Mark Rutland , Thomas Gleixner , Kent Overstreet , Vlastimil Babka , maged.michael@gmail.com, Neeraj Upadhyay Subject: Re: [RFC PATCH 1/4] hazptr: Add initial implementation of hazard pointers Message-ID: References: <4167e6f5-4ff9-4aaa-915e-c1e692ac785a@efficios.com> <48992c9f-6c61-4716-977c-66e946adb399@efficios.com> <2b2aea37-06fe-40cb-8458-9408406ebda6@efficios.com> <55633835-242c-4d7f-875b-24b16f17939c@huaweicloud.com> <54487a36-f74c-46c3-aed7-fc86eaaa9ca2@huaweicloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 34EC4180015 X-Stat-Signature: 9ad9tfhygtyq795mj8rbz7d1a6q86bwc X-HE-Tag: 1727395343-649159 X-HE-Meta: U2FsdGVkX1+UWAIfQ67kv2UtNvEgRWgNFkdLt2rwCyM3RM7BMCtZNWV9iYJsJwzqeS73sXu5dWnyGT0uP6aiy+V9SpLjfwC3TrmqPYxWH61lWgKeiBqaMLtYkB0zCZg9j+vze0veqXnc41CaEMwkCRTauUc34XPtTsIDr0seZY3R5qe5+YH2WOEJP2TiB/hjvvavhrnt4NcRtspKX/7AJsjVhrBlY98cEicJnfPGtRA3C9DTftMk8HzzPF8gkPzajN17am/yiAHYBwjp7TYRhQSSoG/xu6hLv78pbVONicYDjVeNu+RQsqSNhZ5jqr4UOp+vIojXB7DpqmaoZlhlsHqBholg7/nCxxOfMekLZyWT1Mpo0hX0/4gd4nomb/5hT0p6YXz/B8+oNDB1z5TDZXdVsG+y3LSC4g2kWfb/Jyv6JjMkhYZcNUITVc+ND1H3UU+UIxnMqlGMPk9aLOnigb4mwAt86BjOoaEOMmPxtdBYkZ2di7pWyDGFXDsEdkjqVa4s0GQxcgT7OT2Mb5MarhSQnTnFBKg/Xr1QwD414OZtFL4jXs52rrQri8kTZ3bvOaxKpc6/PrCADLw6OzcBEdvqoqybxGvWIgiUe2AUs5FL5/SDtfPgM2YUbx4Vf0xuFOxJpuh1rBbWdQ4qzquMl2H8vCaZdMKy9Zurp1BFj7BAivHtjgIs+/1IfBUG8UGDVc6W1SP7bHfrNh7Fs3jcjqM7USHgbYLLk8EMgmfVOkc5xkMtosxv6tyOi/w70/c27YFIShEtLD2V4agpHvPUfcmsdK0OBe1Yfsw/t9S2pi+Wf+pjcPe970mR/W5T8/XusEY+SDcZMGn2vRa7t2BGoIh1I1w1Ps+ct+c9W0H/wxUifsIi17wa3d8/9yVzQzA68eStPs8JsfDfz8nYsrLrruypo/e5lLNwitow6NP+h+80s8YUPmPnD1vijT/TjD3dHegKN7AzW7K/sO4daNb cWREGAc2 f0lPqeLnZouVUxYZ5tKfd1f0YCPdnN9NDD9TqLVAUTnGUHGnvWAMVAg6jjBV3KfTrmt1wAFJsG+7mwVXPzbzln+w/Cxgf0Gd6e5kwWMss2iUX4NeYwWOMsp2oaU4/9joi+bn9n7+z0Azjphja0jB515aYuK9pgv2D1T/jP9k+c/rvN+s0gGYPHicdvuaVvdPDAg+BkPPU4MYGwl8pYuTNsI8C218o1rhDvN78xqJlHCYya6LYj2IA2lX+hCF+jVAW3eV7rdE91a/Rh3gz/B25fsWKmcOnvg2b8TpcGrtGn6wk/s/eFmXFBro0VUgN3cyOmPTVK6I3YGZPrgwj7MTjvhx75IPkvWzvtmkKutQ9wLitjH5if1gTlOCXu1C/sQKNZnOl/rylreM7113jWz2uuc+USTDH2JAvCIDP2g4rpuOLnH3IpawmIj8cjIr02W2rC/58UYGMAIyHuWvY5jZCdynhYN0uVZJUAOnknt48P5OSPjaM0cGSOHjXxAIXJZjxi7MF 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: List-Subscribe: List-Unsubscribe: On Thu, Sep 26, 2024 at 09:54:33AM -0700, Linus Torvalds wrote: > On Thu, 26 Sept 2024 at 09:40, Jonas Oberhauser > wrote: > > > > Boqun seems to be unhappy with a barrier though, because it would > > theoretically also forbid unrelated optimizations. > > Well, doing a "barrier()" is kind of a big hammer thing, but honestly, > I don't think we've ever seen any real situation where it makes a > noticeable difference. Yes, it can pessimize compiler output more than > strictly necessary, but the kind of code generation issues it causes > tends to be the non-problematic kind (and particularly the kind that > even a trivial OoO core will deal with well). > > We do have some more directed compiler barriers available, and this > code might be able to use OPTIMIZER_HIDE_VAR() for example. It's kind > of a "single variable value barrier". > Hmm.. this seems can do the trick? #define ADDRESS_EQ(var, expr) \ ({ \ bool _____cmp_res = (unsigned long)(var) == (unsigned long)(expr); \ \ OPTIMIZER_HIDE_VAR(var); \ _____cmp_res; \ }) i.e. compare the address and hide the equality information immediately, so in hazptr code: ptr = READ_ONCE(*p); // first read if (ptr == NULL) return NULL; head = (struct callback_head *)(ptr + head_offset); WRITE_ONCE(*hzp, head); smp_mb(); ptr = READ_ONCE(*p); // read again if (!ADDRESS_EQ(ptr, (void *)head - head_offset)) { // pointer changed WRITE_ONCE(*hzp, NULL); // reset hazard pointer return NULL; } else { // Optimizer lost the information on the value of 'ptr', // so it cannot replace it with head - head_offset. return ptr; } Regards, Boqun > Honestly, we don't use it much. It just tends to be _too_specific. But > it is there if somebody wants to use it. > > > But I have not seen any evidence that there are any unrelated > > optimizations going on in the first place that would be forbidden by this. > > Compared to something like "smp_mb()", which is not just a compiler > barrier but also generates typically very expensive instructions that > completely mess with an OoO core, a regular compiler barrier is a > complete non-issue. When you have those two close to each other, you'd > have to make up some very odd situation where the plain "barrier()" is > even noticeable. > > Linus >