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 458B7CF6493 for ; Sat, 28 Sep 2024 11:35:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BAA556B01AA; Sat, 28 Sep 2024 07:35:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B59D86B01AB; Sat, 28 Sep 2024 07:35:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A6FC66B01AE; Sat, 28 Sep 2024 07:35:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 897D26B01AA for ; Sat, 28 Sep 2024 07:35:46 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E140D1211D0 for ; Sat, 28 Sep 2024 11:35:45 +0000 (UTC) X-FDA: 82613942250.07.88CFB93 Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) by imf17.hostedemail.com (Postfix) with ESMTP id B5F6E4000A for ; Sat, 28 Sep 2024 11:35:43 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=hOr8uGwP; spf=pass (imf17.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=1727523221; 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=4cToJeN7JxSuJxkbur1XPF3iirKcu0HneXY0wjqTA9I=; b=6IDDeJN85bNZKM9DulVidhJ51NaqtJg/Wi+yRqORQsQWrELtYG12MzVaIePP8FihVrqHm3 cXyvbHIU8ufD4DFqMFrQoXxXcjbTnEJJrNWjEakgDJghbocm1W1CNKDO8uTFEtRWfqsfPR sj3c05hOoDZxNOIBRuLYoCtiJ29Ty4I= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727523221; a=rsa-sha256; cv=none; b=7CtV+n+yqVNQLR34L+wDdqc+aXtJZGxFCOGfxFMnw7k+BDX9xZ51F6nFCJvnk++izwXv6w QtewzSSi+LBg7OhcE0YVlnmWFbtpEuVqfvagj2AxLHg+mfw1OhHh30b+j9DGKoVgAoI5C8 1O+5/hbn7Rm1LV3PzIAhTrLeskuDDvY= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=hOr8uGwP; spf=pass (imf17.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=1727523342; bh=5lMXHFtn0jEoSxgXj3YeXoWW7aLl3YwVJkTxD0aY9Cs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=hOr8uGwP1TTSe8m6DHD671x0tWa98Xb1hZRss8eWxYv6g9Qor63TrPpXcP7obYlms tnYPBRGIq97iQBkWPmB3s7CC+7GIGMuACO1mXtqtpUxkJGejBXFoxwfXM/eTXk5thW zhKZ8DTE2zeu6IpLnsRCeQyPyQD7WggQ0wQEK8QY7kl2j85U2hY5a7JiTo1pEeaqtE rUd7hS88Omfqk+EGtsd9N3rPTNnaookz4corTEJkQ9ssAfexpbTGU6jhX4kOkfNLae Qf6foZYIXejmOAM4PLp97DJd3F7qUZmnt3cEvAmTkTHYJbLxh8UgROs3DuwtdGhHqE 4RTk5216pVDxQ== 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 4XG4yk2Ys7z1Zbx; Sat, 28 Sep 2024 07:35:42 -0400 (EDT) Message-ID: <2ca589bc-2a60-48ef-95a0-d9ee4a814dea@efficios.com> Date: Sat, 28 Sep 2024 07:33:37 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 1/1] hpref: Hazard Pointers with Reference Counter To: Jonas Oberhauser , Boqun Feng , "Paul E. McKenney" Cc: linux-kernel@vger.kernel.org, Will Deacon , Peter Zijlstra , Alan Stern , John Stultz , Linus Torvalds , Frederic Weisbecker , Joel Fernandes , Josh Triplett , Uladzislau Rezki , Steven Rostedt , Lai Jiangshan , Zqiang , Ingo Molnar , Waiman Long , Mark Rutland , Thomas Gleixner , Vlastimil Babka , maged.michael@gmail.com, Mateusz Guzik , rcu@vger.kernel.org, linux-mm@kvack.org, lkmm@lists.linux.dev References: <20240921164210.256278-1-mathieu.desnoyers@efficios.com> From: Mathieu Desnoyers Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: B5F6E4000A X-Stat-Signature: hktuu7wfgpo6mx4a9y74kgigibemga98 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1727523343-907879 X-HE-Meta: U2FsdGVkX1+ojffOzT3QX9iQ21HdyB1PQtv6j8lAG53jwEBgJukvYKPoFCRCBMIWNu/aj6c2p2S2+hmKC59BTgx3kK/MoRq1idVCetptaHQOGSlQab2vtogxfCHUjcrUIoR7xzdguOw6cEd6jZvV5SIrpH8KAp7DAsDgYnTrPb5NVCik1c4MFRiD6yMzMhZb9Wog32JeWGo4bybWGHKdONXx5SvJlGZ3a2sD39oDGDP3NCKd1mm1ugp/fmM8vsN3eTVFh4FdEIdRAALc8GjaNg9jbe4jNQ6cwka2Bs4m40KF+hSmIJR/I2bt8hsxhR+iXVJ4SDm5TwQBnb5orVBeGFWZXuKvVvWGfL+7PRci3VsCXWYI8l3RVHFzjXXAs/lX5hQ0vZ3/LIXuTrwe1/gS2Y/ou7hH1q9nh/RnaayR+Oc4rY6ByVBL221qeIFFnChLcolNSS0A2bCI9vGJjRxyzHDR/yvyXIWtl4AytqD9yKfK3jJJcBBU3HfcLznOMz9ot1EsGAzcgIfkaRrI86MIIWxkmrJ+kRmjxJzEVR2brIfGBHv1Z0+cRATBZ8/JwXuZFTWfkjAJZMfh1A9RAnS+CcULrzI2mmDMdRcbwWltkPvKr7aJGZkQijzVEuxJmcTdy0Rbci3V/NAH7UfP7ge0gU9USDtKZ1lzXSnyIxhB+UpyVlI/STT9MAyV9+p2j+EcA1qwzfh6gbx+zE3oIUgDNFLHLnc95WNtOTJTIhFX4/DNKgIaXY7UfPcq8+50o3xkCJhEfTUjf+UYnOtWgawEcYDIqrR9RrY7lMV2VZ18VtomdJ07tNuT8iNuF0z3AToOhNINLqMrdHCq3HzC0G5mpjely2IIKW2mznSMLTbcR0DZC5kNMIpnsH+u7LHNI6F9fZyl+quXb86Y2BkNolYirt/5v7sklQsr8bB1swpYkXlLnPTZU/w+9PbduHGmRymOVXLd32KJxVHW9gKyFx2 CnFf+37w xZ/5X1Ho06kj0V9VH4Vz+4W7uDhQpUQK2PKRt3hYpl8MJ+lHk5+IVoDwd8PMiVX658YHLx5uBCijdJnfGK4BPcufxE9Y3eR93SoMF3ymZ5V8TMcxRoeJvVgxXD0NV8rVoSAaNg1HDC7RmUhxVA+V0znz2cFT6nZOWqw6DL3tMnCoHThgqyuaqlle8oa6mOJm9swtzkmegcrL1/nYySLL+OIek3Wgj1LUu6CPoVanCptIP2eo4sM2FozyUnvXhsb5rSolalK3Abdar06aFBDW1Nn6RScjGICG0MIkVvQKkQITWvemMqmqZB6xwa4eB8l18iqfNd0gtF299mv9SIV3sdPSA9p+X023q2U1NWoxANLRAYYtfS8Zg5OPa+u27Nso7x42Gtk4oEfFto88PS8QQ0Y/stFPBhvFw8LrtiqEuc3OoBWLbmHtHujLr/M659KFr/FrfXD5fUSGmIlkV3Sv8UOaJDVQhYeKjEI/Y 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-28 13:22, Jonas Oberhauser wrote: > Two more questions below: > > Am 9/21/2024 um 6:42 PM schrieb Mathieu Desnoyers: >> +#define NR_PERCPU_SLOTS_BITS    3 > > Have you measured any advantage of this multi-slot version vs a version > with just one normal slot and one emergency slot? No, I have not. That being said, I am taking a minimalistic approach that takes things even further in the "simple" direction for what I will send as RFC against the Linux kernel: there is just the one "emergency slot", irqs are disabled around use of the HP slot, and promotion to refcount is done before returning to the caller. > With just one normal slot, the normal slot version would always be zero, > and there'd be no need to increment etc., which might make the common > case (no conflict) faster. The multi-slots allows preemption while holding the slot. It also allows HP slots users to keep it longer without doing to refcount right away. I even have a patch that dynamically adapts the scan depth (increase by reader, decrease by synchronize, with an hysteresis) in my userspace prototype. This splits the number of allocated slots from the scan depth. But I keep that for later and will focus on the simple case first (single HP slot, only used with irqoff). > > Either way I recommend stress testing with just one normal slot to > increase the chance of conflict (and hence triggering corner cases) > during stress testing. Good point. > >> +retry: >> +    node = uatomic_load(node_p, CMM_RELAXED); >> +    if (!node) >> +        return false; >> +    /* Use rseq to try setting current slot hp. Store B. */ >> +    if (rseq_load_cbne_store__ptr(RSEQ_MO_RELAXED, RSEQ_PERCPU_CPU_ID, >> +                (intptr_t *) &slot->node, (intptr_t) NULL, >> +                (intptr_t) node, cpu)) { >> +        slot = &cpu_slots->slots[HPREF_EMERGENCY_SLOT]; >> +        use_refcount = true; >> +        /* >> +         * This may busy-wait for another reader using the >> +         * emergency slot to transition to refcount. >> +         */ >> +        caa_cpu_relax(); >> +        goto retry; >> +    } > > I'm not familiar with Linux' preemption model. Can this deadlock if a > low-interrupt-level thread is occupying the EMERGENCY slot and a > higher-interrupt-level thread is also trying to take it? This is a userspace prototype. This will behave similarly to a userspace spinlock in that case, which is not great in terms of CPU usage, but should eventually unblock the waiter, unless it has a RT priority that really prevents any progress from the emergency slot owner. On my TODO list, I have a bullet about integrating with sys_futex to block on wait, wake up on slot release. I would then use the wait/wakeup code based on sys_futex already present in liburcu. Thanks! Mathieu > > > > > Best wishes, >   jonas > -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com