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 CCC6BCDD1D2 for ; Fri, 27 Sep 2024 20:04:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 619616B013A; Fri, 27 Sep 2024 16:04:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C82C6B013B; Fri, 27 Sep 2024 16:04:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 468DB6B013C; Fri, 27 Sep 2024 16:04:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 294D06B013A for ; Fri, 27 Sep 2024 16:04:39 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A4D791A0EC6 for ; Fri, 27 Sep 2024 20:04:38 +0000 (UTC) X-FDA: 82611595836.29.7AFE23E Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) by imf01.hostedemail.com (Postfix) with ESMTP id D037B4000F for ; Fri, 27 Sep 2024 20:04:35 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=JcEpl4Wq; spf=pass (imf01.hostedemail.com: domain of mathieu.desnoyers@efficios.com designates 167.114.26.122 as permitted sender) smtp.mailfrom=mathieu.desnoyers@efficios.com; dmarc=pass (policy=none) header.from=efficios.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727467353; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IjyDKK9Z2BuFdvOzCaPLptIFw62QIcricsYwr9ivk8k=; b=niD8R9SlRyyy0fKZBySACCkZ2T5UAl/0Cb7RNJz6dT9yb3wDLx4CzlNbKV1/TOwAdWouWw WpM2STyXgH9FB/XknIiHG6VtzcrpedToYLV5uJqWsZLkbzdAGlQiDuGbTldSabIyG9alXx uU2S3qMHI6VRGzwqQlOizejHrU00wNI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727467353; a=rsa-sha256; cv=none; b=iwIL92hY7fh/1BhD3BcYKifUuIs+dXCSV1LLFzj0NLb6toVlMUzThmhkx6IaBZdW8c1pL6 eAAT7RAXz4J7g+PIFzU3FTF+G4Vw5OyN05igLz1mKCEkd59+/RHgbNC3KL9xamWkNkRAlJ nVkF2xRIK/5uGHpvFyI6bgCvpF+Abfk= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=JcEpl4Wq; spf=pass (imf01.hostedemail.com: domain of mathieu.desnoyers@efficios.com designates 167.114.26.122 as permitted sender) smtp.mailfrom=mathieu.desnoyers@efficios.com; dmarc=pass (policy=none) header.from=efficios.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1727467469; bh=ZyzKzMwioxUsX4rJkQ2DEpZ6Xf1fCqB/veO3g/+mn2E=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=JcEpl4WqXJQjtF7BSqtzi1zilLR2MrFkyOxiVUGDqxv8V3U03iUURCDM5spMotSCg QqUmZi3N43WlhwYtWnD4h2gnI5VmRpPEk3CxxXDE2j8a+N3aJf3s9awSpB/WkFd4ha 9nuDa4+6eO3Yem7kTKf4UY9k4ffQ1VRIgBYCxXxJYwngUHAXOnvRnbWWMn2x70B95z /6tWt72V64np4nqgU79JBLw1F9+lrQ8PPisaFdeAJp7GE7TBQR5zLEc97n2bEunijt 0tpbWEybDD2eWSgOhoACJo2nuii7Xt2V87y0SuQU/U8+JKe9TmfGmm4h3rpuHyJWbB 4r1csMNzskdRA== Received: from [IPV6:2606:6d00:100:4000:cacb:9855:de1f:ded2] (unknown [IPv6:2606:6d00:100:4000:cacb:9855:de1f:ded2]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4XFhJF1W9xz1RH7; Fri, 27 Sep 2024 16:04:29 -0400 (EDT) Message-ID: <8b45d5bd-b36d-4703-8a75-81e6bc871a9b@efficios.com> Date: Fri, 27 Sep 2024 16:02:24 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 1/4] hazptr: Add initial implementation of hazard pointers To: Linus Torvalds Cc: Boqun Feng , Jonas Oberhauser , 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 (Sony)" , 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 , Greg Kroah-Hartman 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> <0b262fe5-2fc5-478d-bf66-f208723238d5@efficios.com> <7e1c8a5e-c110-414c-8fb2-022eacc2bd4a@efficios.com> <34ec590c-b109-44a0-8bfe-8aafc6e7ad64@efficios.com> From: Mathieu Desnoyers Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: o7ai6yjcj8bz81dmasontznw91bgowys X-Rspamd-Queue-Id: D037B4000F X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1727467475-242929 X-HE-Meta: U2FsdGVkX1/kJa83Nsmyzgd3sMqPZmRqGbrQSgioZfDqNaWAhSnakldcxGPequT1mTkd4FPXLHKhaI2+iBv6YDTIA+QOwXZfS22jWHJM7pVJixMsaEc3zIqxx10IXAcW7kDybGb9MMg3QZj9ea9ofPo8rZ/nJetVwTHpysztjc8kiCdhQ/AF3jc3PrpYSjawrz/6slrUEbQVqTp/DUhSS7QGAFa+B86DjoafNtM0befX94tBMVi7d/JZuPwWdpTare1ej5bVg5WMZKITo91atIsJmHdCD6INrAP3NKBMqT8kncDSyrFERr5ZJn29lZWUaYlEMHe6YpU+4WMh8gxFFTy7x5r01YScucECGt1sYLrRs+XzFDBfuMIDdbkQCns2vBmz5C2Y71iiPAsnlEm/YZ5nM+IPgPaTBJaTZ3YTPq8kS4FOSqlZog+Mn2rN8KDmmSVq1/kYqtF8Ad3pjjPmmQj6Euv4fmpdnJXxl90lfu6dXmxECte5X18W0Rftu8ineB2YfTO/R/QZN1jpe/6HHjIkUupaxXguxnEgUrITvEpRM8KepafQsGmUeElws1hw7ChAT3Nu2TWWN6KE0K7TFJxxSMCNCFtgOqyzChpBV8qAHM84SfVAtfHI6x87ws86xxWOSGGqeA7FETFDX421ZzGSDwGoph/NEIXrFT9/PkxJ0hHcYP2cdUn8IDMW9+rak9HI5sUD+U4a3J7qv2opbno3Tl2CEnksQFw36tScRVRBFgLXwpC1wD5mubQE8k2bkDH83wH1f7o4XF15HqE7SFlqXgmd12NsTV9J669iCoDqQiPdEuwBQiBf3HgNzdcaV+c/RW3SWSMyV1ZQv8BUg3HYLQrInx8VjlDw0lWARgt2pU3Nr/EF00DupBo64AiZoO5BQXv2rM+DwukWNck2IdfsaW71pnhvq/MAwgIuw2g5plcUReOmNheQNyY8fL2o5EmXyECCnYKfWsWGnoo x/Jnmd9D Lx+GtPDLrEanIHRBKai8zD6B3J8QeN9WDiZCD3rm05ktHGYuXRq9td1WnWA4wrijD55CYezZ0z9MgaRd0Jg9eL276eMtHXlwa6NdgrrsAtg+GJEm58C8GK6h8GaQs/hGlAgR57QQzEVLoBMJDEhziLCevzXMBUG+frdivRKTMawO8t7wWBLq72IjCeUeAwjxHuODSXp2q4qPsaA7vHiUBmMisMf/NGEZcIVG9BBEv1bcA3eHQSJqMFKk7fqDr9HEPjTCGibejiCX18LdEAD6TpYwQar/LoSPptioOCmWeRdG655YhzNggzZHGS6ouQUB6Fs57YM1XWu9XIVrFx0UwXNfNWNbvLvootNPIoFC9Sfii2eCdgnZb4NdnDUXyHZnUZ1n4H/G3FQJtXVFxwljZq1r156FRcsC9k94ejdfKTlBWl29s4zHv8zRerJ0MovNbgshSkvpUZizxFOr4x6lkK5QMDfE/prvDnnMP+7pmqMuC8rg= 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 2024-09-27 20:13, Linus Torvalds wrote: > On Fri, 27 Sept 2024 at 10:53, Mathieu Desnoyers > wrote: >> >>> (b) the value barrier needs to be on *both* values so that the order >>> of the equality testing doesn't matter. >> >> If we use OPTIMIZER_HIDE_VAR() on both parameters, it indeed minimizes >> the odds that someone get the order wrong, but it disallows using >> ADDRESS_EQ() with a constant parameter > > No it doesn't. > > This is trivial - just hide the source of the *comparison*, so that > the compiler doesn't know what you are comparing, and can't use it to > then replace one with the other: > > static __always_inline bool compare_ptr(const volatile void *a, > const volatile void *b) > { > OPTIMIZER_HIDE_VAR(a); > OPTIMIZER_HIDE_VAR(b); > return a == b; > } Cool! It works! Thanks! > > compares two arbitrary pointer values without allowing the compiler to > then use the comparison result to use either of the original values as > a replacement for the other. Yep. And the static inline is much cleaner as it allows users to pass constants as well. > > And yes, that "hide both" model will cause a bit more register > pressure, because the compiler will now compare two values that it > really thinks are potentially different from the originals. So you'll > have two "useless" temporaries that contain the same values as the > source pointers, but if that's the cost of having a comparison that > the compiler can't see, that's fine. I've tried it and it seems that the compiler only leaves one "mov" extra there, since the extra register movement on the input that is not used afterwards can then be optimized away. > > Making it a bit less obvious, you can hide just one of the variables - > you don't actually need to hide both m(but for clarity, maybe you want > to). > > Because even hiding the value one from the compiler will mean that it > can't use the comparison to decide that the originals are equal, even > if one of them is unhidden. > > No? I would prefer hiding the two input variables. Hust hiding one variable might work for CSE (and light godbolt attempts seem to confirm this), but I'm worried that it eventually breaks when compilers start making SSA GVN optimizations smarter. AFAIU, in the SSA GVN model, if we just hide @a before the comparison and don't hide @b, we'd be in a situation where the compiler could know that the version of the variable generated by hiding @a (call it a') is equal to @b, and therefore when using @b afterward could instead use a', which is derived from @a rather than @b. It may not happen in practice just because why would a sane optimization would prefer using a version that is deeper in the dependency chain (a') rather than @b, but that would be based on assumptions on how specific heuristics work, and would therefore be fragile. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com