From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f48.google.com (mail-oa1-f48.google.com [209.85.160.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2D366481DD for ; Fri, 19 Dec 2025 02:33:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766111612; cv=none; b=CxBXt6UG7myfPlkOeQItDqKTvthGOJkmllrr9yEX50nyeI5ACmiWtBMQAuMiMrw0/ks+bycE73aVt1t/vJj335nOGdK2F+N8/blCg/h2WJ4QA5PFUyZSAhj5txe+VzxN45AGFKEwXlSlZtxU7fZcewxbr1SdEORpwpSmXlci2Ho= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766111612; c=relaxed/simple; bh=is9YxCrTIYETTKLl2H7AGTPR3Ds83Cfd0CZETLRxHhA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=C5f4kOtPtS0OvrK9oZdVGz9VWTXP4ND58aq88ab9s93CpfWlxW1iFLfy8fJo9jasAPJxN/eBGnomN6GO3/dxpSX7c0norJdeD/j/7KpAwkeRcOPyC5mOpn3VbFv1E7rrgmPXKkDc5JgzqYhfET7ShNcVP6EyJ88en3KmBqOYeIo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=KBQlPO9z; arc=none smtp.client-ip=209.85.160.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KBQlPO9z" Received: by mail-oa1-f48.google.com with SMTP id 586e51a60fabf-3e37ad3d95aso952747fac.3 for ; Thu, 18 Dec 2025 18:33:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766111610; x=1766716410; darn=vger.kernel.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=l8X/mpvTeafKM3nH85dScPT9I6f8OgbfxSkwYBazOi0=; b=KBQlPO9zwYJXblRY1x15Np1jwmfy12LFZ0DNenBb7495rJ9TVr9zLu2/T78Xo+TIYi CwVz/761xlCLLxhnGE67Bc6NQvHPVgODNG+iD4vchcsXB83TrKpYj2CHa7tycxp35DRw QEelXbdJ3fLC7XOK88XEZXbPk3o9NiE5GuPz0dWqRgVfmnO0jHh0h2sMNd10FymgNtPw dA43Mirg5FYUzFLkGKqSWm7ovpYKgln6PccSNB2BdR75/SXYeO+JciF6+PKbzxPbESW2 dK/xYPkGrshnCh+pWmnw+HriHrIOXldAc+wGyueJaZGBfU36afY3CKMSj+mHdSbwz4I1 qDVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766111610; x=1766716410; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=l8X/mpvTeafKM3nH85dScPT9I6f8OgbfxSkwYBazOi0=; b=UD68ChWtngX0/Bvmrei8DfLXgUW7ccxXlN2ZmUY7ERIVEuzCpgn1F7IVgY/7jOuHou Efkbw1QeqrKZw7D/YPWWOSJHzlUiXMBXxyd34mIZEJM4htMMxzLN/6dzvQZSJutSa8yp 39d87odgIGfP0TUwEAOtcS1xRe9QC77AYrtguGIBaB+1N9Ktq0f398QkuF6yoCkw4pzc rjH7xVOIEaW9vTUIp5vj8vxcXD/QbWljswFeFm/auH6DLF7JvXQ6Yu2MVNxZ+vWk1A2p iuQP9E707JJkEqhPFmc+6zJ4Gp4sU//bF2WC/VynqAnjzzdN3amoNYNcF4FiPnj6GEfE PL1w== X-Forwarded-Encrypted: i=1; AJvYcCVkFiepNyeIqNl64UrzbaJuu/l3Fkj6KWgS0WhDWSjXU1uMMiiQ5oXgALLB0iF/bvE5kCSdP38vzk5yLw4=@vger.kernel.org X-Gm-Message-State: AOJu0YzaN2vrF+A2a/GXXmWcXijE3Nt6W57I/xir81AoqyhDON9sofDd kBMH6RVgQ9rbYAG/d+gjaL/EQ8cSoFEwW6J9mQU3mfUBY5EbZ5QDfSgPnaZBeS4NhTc= X-Gm-Gg: AY/fxX6QuFEGLzEWiufkd3tz+bG66l2I5kr7N3yt1I+XpRlfE+onJkX1xtA6WIbY+fv NAM5oXapVHXS7OdkhAsGGr3SSiXz3dAxQ6y1FQ+mQ+TwtGNBhnaUt43bkXa0srVi+hfGl2mierl FHWxArHw0BerJqeoCJLFh/48NNciPU99ddWieZf2Sz0AqGhUb3Q+3c9695hY1jvg1a2+eBWXEdM ySFafCpPZr9hRqFq/KqCPcb9U5v7gwYIofrAmvbkTlW6mZ87dhnbvmqcw2hw46AzJwUtrf36nv2 El76V2bBa9D+WAxLddBeiRDpq/zqwoV8i+ErP0kf+tRHfIhTMdDAmMCdO9zNoIjJaioQetnsRaM lnND22LlbMFuzTbKQ0CszaBlzCueb7OhxEcAPC2XhumYjnC1uH5+BMStrmbo5VMBY2TKxrjINRr wpe8CiF4ZRqHMa0uyCxN/o0sCquu+2u7B3dPQnvRoTc0IA1F4TVmes0R4v3JbmaAXMLXqMlqQn8 R0x5iRWlxFRu+4= X-Google-Smtp-Source: AGHT+IFPk9sbtY0UjBkjpQV6F8R4ziD5cSSxeHmFqbLe73zBnLmXKITpnuraJGxLeqMdGtMo3KFVAQ== X-Received: by 2002:a05:620a:31a3:b0:8b2:271e:a560 with SMTP id af79cd13be357-8c08ff218ebmr212306185a.72.1766103947460; Thu, 18 Dec 2025 16:25:47 -0800 (PST) Received: from fauth-a1-smtp.messagingengine.com (fauth-a1-smtp.messagingengine.com. [103.168.172.200]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8c09689153asm61478885a.17.2025.12.18.16.25.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Dec 2025 16:25:47 -0800 (PST) Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfauth.phl.internal (Postfix) with ESMTP id 25E38F4007E; Thu, 18 Dec 2025 19:25:46 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Thu, 18 Dec 2025 19:25:46 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdegieekiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpeffhffvvefukfhfgggtuggjsehttdortddttddvnecuhfhrohhmpeeuohhquhhnucfh vghnghcuoegsohhquhhnrdhfvghnghesghhmrghilhdrtghomheqnecuggftrfgrthhtvg hrnheptdetvdfgueetkedutdegudegfeekffevgeetleehvdektedvteeggfegtdevtdeh necuffhomhgrihhnpegvfhhfihgtihhoshdrtghomhenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsohhquhhnodhmvghsmhhtphgruhhthhhp vghrshhonhgrlhhithihqdeiledvgeehtdeigedqudejjeekheehhedvqdgsohhquhhnrd hfvghngheppehgmhgrihhlrdgtohhmsehfihigmhgvrdhnrghmvgdpnhgspghrtghpthht ohepfeefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehmrghthhhivghurdguvg hsnhhohigvrhhssegvfhhfihgtihhoshdrtghomhdprhgtphhtthhopehjohgvlhesjhho vghlfhgvrhhnrghnuggvshdrohhrghdprhgtphhtthhopehprghulhhmtghksehkvghrnh gvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghr nhgvlhdrohhrghdprhgtphhtthhopehnphhighhgihhnsehgmhgrihhlrdgtohhmpdhrtg hpthhtohepmhhpvgesvghllhgvrhhmrghnrdhiugdrrghupdhrtghpthhtohepghhrvghg khhhsehlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdhrtghpthhtohepsghighgvrg hshieslhhinhhuthhrohhnihigrdguvgdprhgtphhtthhopeifihhllheskhgvrhhnvghl rdhorhhg X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 18 Dec 2025 19:25:45 -0500 (EST) Date: Fri, 19 Dec 2025 09:25:42 +0900 From: Boqun Feng To: Mathieu Desnoyers Cc: Joel Fernandes , "Paul E. McKenney" , linux-kernel@vger.kernel.org, Nicholas Piggin , Michael Ellerman , Greg Kroah-Hartman , Sebastian Andrzej Siewior , Will Deacon , Peter Zijlstra , Alan Stern , John Stultz , Neeraj Upadhyay , Linus Torvalds , Andrew Morton , Frederic Weisbecker , 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 , Jonas Oberhauser , rcu@vger.kernel.org, linux-mm@kvack.org, lkmm@lists.linux.dev Subject: Re: [RFC PATCH v4 3/4] hazptr: Implement Hazard Pointers Message-ID: References: <20251218014531.3793471-1-mathieu.desnoyers@efficios.com> <20251218014531.3793471-4-mathieu.desnoyers@efficios.com> <42607ed5-f543-41bd-94da-aa0ee7ec71cd@efficios.com> 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: <42607ed5-f543-41bd-94da-aa0ee7ec71cd@efficios.com> On Thu, Dec 18, 2025 at 06:36:00PM -0500, Mathieu Desnoyers wrote: > On 2025-12-18 15:22, Boqun Feng wrote: > [...] > > > > Could you utilize this[1] to see a > > > > comparison of the reader-side performance against RCU/SRCU? > > > > > > Good point ! Let's see. > > > > > > On a AMD 2x EPYC 9654 96-Core Processor with 192 cores, > > > hyperthreading disabled, > > > CONFIG_PREEMPT=y, > > > CONFIG_PREEMPT_RCU=y, > > > CONFIG_PREEMPT_HAZPTR=y. > > > > > > scale_type ns > > > ----------------------- > > > hazptr-smp-mb 13.1 <- this implementation > > > hazptr-barrier 11.5 <- replace smp_mb() on acquire with barrier(), requires IPIs on synchronize. > > > hazptr-smp-mb-hlist 12.7 <- replace per-task hp context and per-cpu overflow lists by hlist. > > > rcu 17.0 > > > srcu 20.0 > > > srcu-fast 1.5 > > > rcu-tasks 0.0 > > > rcu-trace 1.7 > > > refcnt 1148.0 > > > rwlock 1190.0 > > > rwsem 4199.3 > > > lock 41070.6 > > > lock-irq 46176.3 > > > acqrel 1.1 > > > > > > So only srcu-fast, rcu-tasks, rcu-trace and a plain acqrel > > > appear to beat hazptr read-side performance. > > > > > > > Could you also see the reader-side performance impact when the percpu > > hazard pointer slots are used up? I.e. the worst case. > > I've modified the code to populate "(void *)1UL" in the 7 first slots > at bootup, here is the result: > > hazptr-smp-mb-7-fail 16.3 ns > > So we go from 13.1 ns to 16.3 ns when all but one slots are used. > > And if we pre-populate the 8 slots for each cpu, and thus force > fallback to overflow list: > > hazptr-smp-mb-8-fail 67.1 ns > Thank you! So involving locking seems to hurt performance more than per-CPU/per-task operations. This may suggest that enabling PREEMPT_HAZPTR by default has an acceptable performance. > > > > > [...] > > > > > > > > +/* > > > > > + * Perform piecewise iteration on overflow list waiting until "addr" is > > > > > + * not present. Raw spinlock is released and taken between each list > > > > > + * item and busy loop iteration. The overflow list generation is checked > > > > > + * each time the lock is taken to validate that the list has not changed > > > > > + * before resuming iteration or busy wait. If the generation has > > > > > + * changed, retry the entire list traversal. > > > > > + */ > > > > > +static > > > > > +void hazptr_synchronize_overflow_list(struct overflow_list *overflow_list, void *addr) > > > > > +{ > > > > > + struct hazptr_backup_slot *backup_slot; > > > > > + uint64_t snapshot_gen; > > > > > + > > > > > + raw_spin_lock(&overflow_list->lock); > > > > > +retry: > > > > > + snapshot_gen = overflow_list->gen; > > > > > + list_for_each_entry(backup_slot, &overflow_list->head, node) { > > > > > + /* Busy-wait if node is found. */ > > > > > + while (smp_load_acquire(&backup_slot->slot.addr) == addr) { /* Load B */ > > > > > + raw_spin_unlock(&overflow_list->lock); > > > > > + cpu_relax(); > > > > > > > > I think we should prioritize the scan thread solution [2] instead of > > > > busy waiting hazrd pointer updaters, because when we have multiple > > > > hazard pointer usages we would want to consolidate the scans from > > > > updater side. > > > > > > I agree that batching scans with a worker thread is a logical next step. > > > > > > > If so, the whole ->gen can be avoided. > > > > > > How would it allow removing the generation trick without causing long > > > raw spinlock latencies ? > > > > > > > Because we won't need to busy-wait for the readers to go away, we can > > check whether they are still there in the next scan. > > > > so: > > > > list_for_each_entry(backup_slot, &overflow_list->head, node) { > > /* Busy-wait if node is found. */ > > if (smp_load_acquire(&backup_slot->slot.addr) == addr) { /* Load B */ > > > > But then you still iterate on a possibly large list of overflow nodes, > with a raw spinlock held. That raw spinlock is taken by the scheduler > on context switch. This can cause very long scheduler latency. > That's fair. > So breaking up the iteration into pieces is not just to handle > busy-waiting, but also to make sure we don't increase the > system latency by holding a raw spinlock (taken with rq lock > held) for more than the little time needed to iterate to the next > node. > I agree that it helps reduce the latency, but I feel like with a scan thread in the picture (and we don't need to busy-wait), we should use a forward-progress-guaranteed way in the updater side scan, which means we may need to explore other solutions for the latency (e.g. fine-grained locking hashlist for the overflow list) than the generation counter. Regards, Boqun > Thanks, > > Mathieu > > -- > Mathieu Desnoyers > EfficiOS Inc. > https://www.efficios.com