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 1735FCF58E4 for ; Fri, 20 Sep 2024 07:44:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 29C826B0083; Fri, 20 Sep 2024 03:44:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 24CD96B0085; Fri, 20 Sep 2024 03:44:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C6CF6B0088; Fri, 20 Sep 2024 03:44:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E6C006B0083 for ; Fri, 20 Sep 2024 03:44:25 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 287AEA0158 for ; Fri, 20 Sep 2024 07:44:25 +0000 (UTC) X-FDA: 82584328890.03.01C4152 Received: from frasgout11.his.huawei.com (frasgout11.his.huawei.com [14.137.139.23]) by imf04.hostedemail.com (Postfix) with ESMTP id D12F540018 for ; Fri, 20 Sep 2024 07:44:22 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf04.hostedemail.com: domain of jonas.oberhauser@huaweicloud.com designates 14.137.139.23 as permitted sender) smtp.mailfrom=jonas.oberhauser@huaweicloud.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726818149; 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; bh=tZH/D87pqm9AZdmOfEW9wR6SX+nDSKle9CBKW+NfElQ=; b=iELhLEgRGYcVcP0ccFf47FBLEa/Ju+hqwKZIlKk8jgW+E5Ru3BZ9uSpP2GSOM1zNmklDOM sJaLdAt7rPwfL28lKUXFoEoiVtlKBni1Q7y6OP7yN6pJR6cVRaEQKtI5ungD66++U3TiYK srf8qZQYOMOvsuzrCxLoy9hWZ1oZL30= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726818149; a=rsa-sha256; cv=none; b=41JMW0bmkpN3RRsK4LECCkXkyWqeoqnrfg8aK8HZKbsT7g9IFy2mLogLvVVS6pz+ZvEXOj YhcZbponVm3bynC0Me0Lh9L3QZRfCRm1KHHq1oBmd/HvLo3y9zE4zRsKCL7SkA/7H4XO2c nQQO7PnjO8SND9dZfdCqjL+Si5UiubI= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf04.hostedemail.com: domain of jonas.oberhauser@huaweicloud.com designates 14.137.139.23 as permitted sender) smtp.mailfrom=jonas.oberhauser@huaweicloud.com Received: from mail.maildlp.com (unknown [172.18.186.29]) by frasgout11.his.huawei.com (SkyGuard) with ESMTP id 4X93ml3bjMz9v7Hk for ; Fri, 20 Sep 2024 15:24:39 +0800 (CST) Received: from mail02.huawei.com (unknown [7.182.16.27]) by mail.maildlp.com (Postfix) with ESMTP id 3AE7C140F51 for ; Fri, 20 Sep 2024 15:44:09 +0800 (CST) Received: from [10.45.149.49] (unknown [10.45.149.49]) by APP2 (Coremail) with SMTP id GxC2BwAHt8e6J+1m+mBJAQ--.61459S2; Fri, 20 Sep 2024 08:44:08 +0100 (CET) Message-ID: <16c2aba7-212d-4612-8cea-50c64626d8f3@huaweicloud.com> Date: Fri, 20 Sep 2024 09:43:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 1/4] hazptr: Add initial implementation of hazard pointers From: Jonas Oberhauser To: Jann Horn , Boqun Feng , "Paul E. McKenney" Cc: linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-mm@kvack.org, lkmm@vger.kernel.org, Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Uladzislau Rezki , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Peter Zijlstra , Ingo Molnar , Will Deacon , Waiman Long , Mark Rutland , Thomas Gleixner , Kent Overstreet , Linus Torvalds , Vlastimil Babka , maged.michael@gmail.com, Neeraj Upadhyay , lkmm@lists.linux.dev References: <20240917143402.930114-1-boqun.feng@gmail.com> <20240917143402.930114-2-boqun.feng@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:GxC2BwAHt8e6J+1m+mBJAQ--.61459S2 X-Coremail-Antispam: 1UD129KBjvJXoWxur15GryfGF17Kw43Kr4xXrb_yoW5AF13pr y8tF4UJryDJr1fAw1UXr1UX34UAr13J3WUJrn5WFyUJFWxGr1Igr1UXr1jgr1DAr4kJr1U tr1UXr9xZry5XrDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvYb4IE77IF4wAFF20E14v26rWj6s0DM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Jr0_Gr1l84ACjcxK6I8E87Iv6xkF7I 0E14v26r4j6r4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7MxkF7I0En4kS 14v26r4a6rW5MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I 8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVW8ZVWr XwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x 0267AKxVWxJVW8Jr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v2 6r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07 jzE__UUUUU= X-CM-SenderInfo: 5mrqt2oorev25kdx2v3u6k3tpzhluzxrxghudrp/ X-Rspamd-Queue-Id: D12F540018 X-Stat-Signature: xbjrf3oc3bm8tmmbmwpp5h1xuyz4y6fe X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1726818262-639771 X-HE-Meta: U2FsdGVkX1/7B/7BZHudJzXkhuQkQU+VZTAiLgIGf2nGNnkh0kdIE857BmA1wqyDivj5tZPRVW4+M38gYLgYyhJZdvYFjXKkhxDFxD9ltMXluViAzO4f/0FQg9ciiAviKCZMdfiCh2kL+kBvQbLoBLWu2nkv4szphYKwX3RyDTlevzxw57yIW15Vm19wsrWVhZXrvjXKYGGIBKCauVvz3/6e0S3w5B1smXp/ZUW/zfPo8rTWoGvqPqg6sQsXFVRRjSfx1sAObAohmez5PxXR/amKh0fVtR3tK57G8BMXUFngaTjzr+I+/bhPEPcDwcNFaVvSsLbHMQzc6zFAsdnmE1KFKwl+MNTd56jGb73/QXXL16lBw3zaCZ3ACrkB5hpJI2frbYVu1x8KxTGEceQ/WqIIoeyyHsHV7AVCFDDwxJGU5KXTBmRgbHWUmE8+ZnQv7CixgKbcCAfoe/oi3Jh6QtxGTC7UfuF2NLF/WqAMIV09nDwcy2Cm0zuqCYzNzIMwGku2b4gp2DUI3LdT1nFvnkRas3mAq51qr6vsagLcxp4qahWjYP6le6+5NhMPuWCvXdnNbLWaJno41iSxOu6vGweN3ZJZi8ykhGkErZGeqqre40wRoPZY3UDiJG5EYuiCbbN/fRLRuzogpvWGUpyAxGLoJ7JK5B3aP6TOxh0lZ2X9EdE1dyRq+vA26WLprF1EQqTB3GfM16XkEPIPsMI6UvWThpORtTvSDmHt84LDqWaf1/kDDcd+MBjID6lMNAD9SbfdUdmXIeHtS8Q9aEUo4jm8Bdq/jpGlIM7+gMmP8vL0wbb7bgzrWw3Ain7rqZAM9IF/QYhsYbBpoCEtplhGZTYJlycaDyLH9o/v2Ysg785RNyAcrhkqevdx6weupR12M3KzZ8H7/APLxigEqIqsFi++n9keMcPilRPb4l2wHrpIi3NymSSm0LShhuFO8tOu9iCIzrxL4oeriVMiTbU tzLY75X5 mOuBboBoEBNRobY8vwVeP+rxlrIppk6L1wq8SU5samwkYZ0AkZb7KJ46Y6xsGOi7xDfuTZ9eBClQEBJ8ZaidMnAhKM1iYUAr2cJgHqhifY5naoaB0WOmNSVyn1aAHXEpdL9Bmb36KXH5eolTPBlwQjarJ0/H23Wo6lJxQG7w7JYtHMVH1SN4Hx06IO34muy1kB/PXldlbQhNhblcVTfIj+f/pmQfQ+QjOuK6jNNNcdplPU/ibcoKFaRHxcBmquO6mVqk+okq01TQGDMrWYzIf3Lqa31cJrq1ou7cZ 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: Am 9/19/2024 um 10:30 PM schrieb Jonas Oberhauser: > > > > Am 9/19/2024 um 2:12 AM schrieb Jann Horn: >> On Tue, Sep 17, 2024 at 4:33 PM Boqun Feng wrote: >>> Hazard pointers [1] provide a way to dynamically distribute refcounting >>> and can be used to improve the scalability of refcounting without >>> significant space cost. >> >>> +static inline void *__hazptr_tryprotect(hazptr_t *hzp, >>> +                                       void *const *p, >>> +                                       unsigned long head_offset) >>> +{ >>> +       void *ptr; >>> +       struct callback_head *head; >>> + >>> +       ptr = READ_ONCE(*p); >>> + >>> +       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 (ptr + head_offset != head) { // pointer changed >>> +               WRITE_ONCE(*hzp, NULL);  // reset hazard pointer >>> +               return NULL; >>> +       } else >>> +               return ptr; >>> +} >> >> I got nerdsniped by the Plumbers talk. So, about that smp_mb()... >> >> I think you should be able to avoid the smp_mb() using relaxed atomics >> (on architectures that have those), at the cost of something like a >> cmpxchg-acquire sandwiched between a load-acquire and a relaxed load? >> I'm not sure how their cost compares to an smp_mb() though. > > > > We have done a similar scheme before, and on some architectures (not > x86) the RMW is slightly cheaper than the mb. > > Your reasoning is a bit simplified because it seems to assume a stronger > concept of ordering than LKMM has, but even with LKMM's ordering your > code seems fine. > > I feel it can even be simplified a little, the hazard bit does not seem > necessary. > > Assuming atomic operations for everything racy, relaxed unless stated > otherwise: > > (R)eader: > >    old = read p // I don't think this needs acq, because of address > dependencies (*) >    haz ||=_acq old >    if (read p != old) retry; I realized before going to bed that I copied a subtle mistake here from Jann's code, we need an address dependency from this read, or it is not ABA safe. This can be done with the small detour that Boqun used: head = read p // I don't think this needs acq, because of address dependencies (*) haz ||=_acq head old = read p // again if (head != old) retry; barrier(); // ensure compiler does not use its knowledge that head == old to do *head instead! *old // definitely use the second read pointer so hardware can't speculatively dereference this before the second read! Have a good time, jonas