From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 040C926F2A0 for ; Sat, 19 Sep 2026 18:09:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789841382; cv=none; b=NoTK/apT7b56Rey0P4WZB54coCFvr9pa74BtT0AfCY1AxdxIuAfmiF/GpJL/QWRnthhmSTRfrxfp0HrJm5AG3DnzQtOtUPpr04CHpdxCcmUsrKf+XizSjMzsddblu4sqCoqKdGECwIsbN0sZLWR3TXR4xINqRZagtfgcq7H7jJU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789841382; c=relaxed/simple; bh=nzrPoy2aSo8Rg+S+rEM2UaTaCM46de/cfEGGM7scxIA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aJgIdwwD9Bn9D8Y5zWyTi74NAU5+np1xIqqDy/Cv9HtJnY/UDtzKfosxbyj8rC8iTQCSkCp66dHJnAw7m3SYrjpidTgxZx/UksJ9u/x89mH5Eqyiw9x4t5mSg0CvAJKW27Hyh4MvYbgAxewCXI2IM03Gv7eRh9JIa1PT7dhniuE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jSkB5Lc9; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jSkB5Lc9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 01A8F1F00898; Sat, 19 Sep 2026 18:09:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789841380; bh=pRkKN54/lEpILJ2Lc3rIPCovoIruayWHBPFvaiFZSfg=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=jSkB5Lc9+CorTFT5giaa6PovfuT3C9FlCn8dm0b+TDP7lsairb0CV5Cgn4gwITAqV QXpgGzktDyPCJ4nbbjRAHNObBHswYpYVabVgrL23Bl3iuzYZOGyNVDDGxvTi7ZlPes vnR5A2EiirGgWpeMazc6HxyDBX2BWikLiMh8KGFLIURelNwDGFyfbROohIzLaxw5AE mDuzMUxvfmlyzK5nopD7JoF1yNjhrRr/J4LB8fRKV3wrWA3njuOzlwNTdWBB98Jjeo ywHMl7vU1D9OUML4rb+8WuTnOSc5nKUHlPjFVvELhuO9rM+MW/Xz//KU13sq83cwyp SGgtBAxpJk5DQ== Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfauth.phl.internal (Postfix) with ESMTP id 1AF8AF40067; Sat, 19 Sep 2026 14:09:39 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Sat, 19 Sep 2026 14:09:39 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGOMHCFM13kMXhSuxN+36n1aHNShRaReTqrePSRKG4sq5ma7+YBTXTUakJSy0zQLM e7xl+opaW4Eklevv6jRqJbW6Ywolp4n2PLcr7z/kaFXF/JfmFMj42KNPrSbAy7BXxgXzKi K4Sf05jy08LVD0d/b1J3hn9fSSOeAwDxxhF1N6NgIYS5pxn06yIyU1et2HdSGwkwcXGE4i MkaDamDvlYs8CbIfaCWEJZfxMLEbM4jNoxyPEVb/dusx2FueAsQu218naoj+uCejFkf0gZ 0vYG0lXFuDvS4tBfEB5M9pQQx6pvb0gUCQVXBb+ThkiDYPQir7M3OLR/P59q2sABs//mH8 j9hsOWIHebLFbWTuuJePNyDqBriGyy6d/HcNofBWa9p99Z+Sml24G4SHR3qrMwDVhvKlaE wvYpp/p3L/t1CwR12MkQWvyCTcZtnvb5M9AojI42S3EkUafdT5Gkm9/OrC3ZgJAUGgfCaJ rl0qLVJo/mjhZ65KxURcNR42IhwuCvrN2mQHcR3BA0e4YRCNpCvwHEPmp0/K7JhOAPXNbm FZvDwo6b7d5c2sle6FZSI042g5+Uud+HZasRlgd5pM+QWrZD6qduHhCKKGCX9Mxb5RleqH WfuLDhk2yZTzIS6HMJ4PMorpBl+Z8liW7G58uEKydyqW98XrqeN00SygaH5A X-ME-Proxy: Feedback-ID: i8dbe485b:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 19 Sep 2026 14:09:38 -0400 (EDT) Date: Sat, 19 Sep 2026 19:09:36 +0100 From: Boqun Feng To: Mathieu Desnoyers Cc: Linus Torvalds , Bradley Morgan , "Paul E. McKenney" , rcu@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, Steven Rostedt , lkmm@lists.linux.dev, Zqiang , Wang Lian , Kunwu Chan , Nicholas Piggin , Michael Ellerman , Greg Kroah-Hartman , Sebastian Andrzej Siewior , Will Deacon , Peter Zijlstra , Alan Stern , John Stultz , Andrew Morton , Frederic Weisbecker , Joel Fernandes , Josh Triplett , Uladzislau Rezki , Lai Jiangshan , Zqiang , Ingo Molnar , Waiman Long , Mark Rutland , Thomas Gleixner , Vlastimil Babka , maged.michael@gmail.com, Mateusz Guzik , Jonas Oberhauser , linux-mm@kvack.org Subject: Re: [PATCH 01/28] hazptr: Implement Hazard Pointers Message-ID: References: <20260919000056.3132131-1-paulmck@kernel.org> <6B1FC39D-6EB0-433A-8E49-E5EFC9379AD7@mainlining.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sat, Sep 19, 2026 at 01:09:15PM -0400, Mathieu Desnoyers wrote: > On 2026-09-19 13:00, Linus Torvalds wrote: > > On Sat, 19 Sept 2026 at 09:35, Bradley Morgan wrote: > > > > > > I think hazard pointers are good, what test do YOU suggest we do here? > > > > I want to see a single real-world example of "look, this speeds this > > real load up by 10%, and the kernel code was actually cleaned up in > > the process because hazard pointers are great". > > > > Not a microbenchmark that tests just the hazard pointers themselves, > > but a real kernel feature that has been converted to hazard pointers, > > and in the process actually shows improvement. > > > > The ONLY reason for hazard pointers to ever be merged is if they > > actually buy us something real. > > > > So I want to see that 'real" thing. > AFAIR, Boqun wanted to use hazard pointers to cleanup/speed up an Right, that's why I send this series: https://lore.kernel.org/lkml/20250625031101.12555-1-boqun.feng@gmail.com/ The gist of that work is basically: On my system (a 96-cpu VMs), the results of: time /usr/sbin/tc qdisc replace dev eth0 root handle 0x1: mq are (with lockdep enabled): (without the patchset, i.e. using RCU) real 0m1.039s user 0m0.001s sys 0m0.069s (with the patchset, i.e. using hazptr) real 0m0.053s user 0m0.000s sys 0m0.051s i.e. almost 20x speed-up. One important thing that I want to point out is in that series, I avoided the busy-waiting in hazptr_synchronize() and made multiple hazptr_synchronize()s share the same scan. And I do want to see this in the new code. But unfortunately with the new implementation, we don't have that part yet. And that's what holds me from trying lockdep integration for this new implementation. I could have improved my skill of time management, because I know at certain point I said "I will finish the scan thread work for your implementation", but it'll be helpful if you or someone can help get that done. > hot lockdep reclaim path. Boqun, Paul, how is this effort going ? > > I suspect we should wait until that lockdep user of hazptr is ready for > upstreaming and propose both at the same time, because a synchronization > infrastructure without any significant in tree user is not really > relevant, right ? > The other thing we could also do is what I did in shazptr, getting the numbers with rcuscale, that can tell use the actual waiting time for a hazptr_synchronize(). Regards, Boqun > Thanks, > > Mathieu > > -- > Mathieu Desnoyers > EfficiOS Inc. > https://www.efficios.com