From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) (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 EA16227FB12 for ; Sun, 21 Dec 2025 09:59:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766311156; cv=none; b=uZnlMgCfW72AcCMktZwUEMi+s9RKN6Oi2RRO1ijOhSGNUm2lorTR+Fr1Yeup2LWem14R+DeNl9PUCRcQ83VAfLYfDMIB76LEeaGPfcuCb4Ds1r6fL8SrhrNiCRC4RasSOb/NbcxEdSdVj0z6gA0XIle/xzgqD3P35GAlPzfGr78= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766311156; c=relaxed/simple; bh=xwKCdQhBtY7sdy8Zz446mEtEqk90qmGnWtG0zOgftIM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SSSmJSntO5PIRHVQrHOQy9ToxsGPRMyFwi5sWkU8jhVTju3rE6rc5HfQGEao1FhWzeaYhoM2K1UHLTHGcJDyAevc/f6VwtA4GL4HTbMrxwgVJkKt9mpUrgC570y3kLraFab1TsvWQ93xRlEzNYo9rgmnBqUA5QBd4Giyf+15tSE= 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=CwpdrKp0; arc=none smtp.client-ip=209.85.160.179 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="CwpdrKp0" Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-4f4c89f8cc6so2807001cf.1 for ; Sun, 21 Dec 2025 01:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766311153; x=1766915953; 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=fjHwQCJ+WLLRT0TZamL7R6ZEjyOxsMVMPGjCn4Gr/2c=; b=CwpdrKp09xpRGbzH4Jv5EF8oQWpU7QngCBfwOhRxFVzv61X6VXGTwnjr9c0U3iRI3m wKmMvefPRORHajYyFoUJfkGMkCKmCJJzVYiHj0SVfGbtS1rgLZMNn1lIZiBFovOq348X dS1dan1yftJh2T5Gy6RaE+dlvruxZrmfRHNKKuDgQXEhJbb2TSpnDcnio65NfnnIsERJ L8scSrPEhybCRwA+RGLhmuYLh5GlQEeBVUq9IVEy7sQxV8/HxfpnIP98TI/UKzUG/yYw mJnwDKgL4Sn2I0I1JcXyrhnnsel1t3Ax/f9YUvwsn2sml/KI1qhk5pHUJ6MqeyaLSe/P 92Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766311153; x=1766915953; 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=fjHwQCJ+WLLRT0TZamL7R6ZEjyOxsMVMPGjCn4Gr/2c=; b=vXFhPnNkvNb4Py6zUq8v0dGVujgUyr2xCEB2reMOt+dQ2GA46W8niNQZpQIHaau5cP ExXSk1qDvipkZMu8AdGX8R/2WbxCXgTfg3y5lUmIeX0MvqbGXLoDmQjzvw37jJlSTqCo snftuKGipaQuIjWRKurJOoHDUeaPj4/rGOv3r+hcAwvIKOU7GSc6kuX8FvLG/Ko9lxwi hduxSKxfGsVnP4t3LLG8KfFAe9y7R+PGRWHXO+5RkeGXIjM91tpSdM3n7kUuDvU0wbk0 WdLkp5WUQUv/JDZhqNPs8cecyn4nKVV0TxJrk2xRguZd0tO3ikqvMyeKNUfOPebs+w6k G4dg== X-Forwarded-Encrypted: i=1; AJvYcCVchCp25q4Pc84wtUei0VyHR7pPKSwwO+vQyefauG0AbDMKvXDavDDOotLFjlUT1+LqoOo+2iJiz2e6W7s=@vger.kernel.org X-Gm-Message-State: AOJu0YwEfr+o6LAAO3aS51DgiIMmuPlgsAJxC9GZkdE81tDheyOz4Yeh mW82bnr1VwD0O79JSlXWqzZ9TFeUdZNduXlLAoDjm9c0YQNw7k05deSG X-Gm-Gg: AY/fxX5prwUfWsI8McI+mgLrvgEb7iaUUNWFxAZ+MBfIx9l+/DQxjEwrqgk+B31m0Cm NPgenW5ysflXEG7GYHlg7Ugx5XPjdgs0uUO5BmoJ0AZuW2YeKz/RpS+MC02n+mkzm72/rWXs1z/ SAu8X4Bksn1qbU57FCfZVHRQrmVZdYfcUKikwTty2LuXWWTmv5TC9geQehFgGUjw2BRz+AWvfRK geYtrJaWtOrmJxB16B4UtTKOO5oH1mMmIasFTCuaXA9zv8IxL0sDirE/JacZMjaeY4n0Je6aiZu JTr85lrlirCaA6sKPIiX7H1mJKGp9wsbHgDD1tQyEbKVNgU+X+I8nVBNxTCe7Huz9HldLjgfcVu RwRL1TpLcKgbyCbE0ZEyW5z6Z5eBkec+2wQxZEcjxUqKqiqigAMyjfi1GM7OrRVADQPAJbcnP0k E9ro065+84M8t1MjEt4FQTQdEtAb0I1DBfMuuWVjcIyA2AN3Mq0ClsEf43VJEMsaRQMvAvBCwj0 Xe6SFfOSdssoQE= X-Google-Smtp-Source: AGHT+IGkZ7YmQ4iCIVP39dS3Dspfdfd6jXXAiK+b4cBzlfzo3Zgdyb/boYNxk+mCnLQREZ4Jn+Teag== X-Received: by 2002:a05:622a:250:b0:4f3:5346:5d54 with SMTP id d75a77b69052e-4f4abd78d8fmr113519801cf.50.1766311152615; Sun, 21 Dec 2025 01:59:12 -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 d75a77b69052e-4f4ac64e43asm54346251cf.26.2025.12.21.01.59.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Dec 2025 01:59:12 -0800 (PST) Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfauth.phl.internal (Postfix) with ESMTP id 06446F40068; Sun, 21 Dec 2025 04:59:11 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Sun, 21 Dec 2025 04:59:11 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdehfeejiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeeuohhquhhnucfh vghnghcuoegsohhquhhnrdhfvghnghesghhmrghilhdrtghomheqnecuggftrfgrthhtvg hrnhephedugfduffffteeutddvheeuveelvdfhleelieevtdeguefhgeeuveeiudffiedv necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghoqh hunhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqieelvdeghedtieegqddu jeejkeehheehvddqsghoqhhunhdrfhgvnhhgpeepghhmrghilhdrtghomhesfhhigihmvg drnhgrmhgvpdhnsggprhgtphhtthhopeefvddpmhhouggvpehsmhhtphhouhhtpdhrtghp thhtohepjhhovghlrghgnhgvlhhfsehnvhhiughirgdrtghomhdprhgtphhtthhopehmrg hthhhivghurdguvghsnhhohigvrhhssegvfhhfihgtihhoshdrtghomhdprhgtphhtthho pehjohgvlhesjhhovghlfhgvrhhnrghnuggvshdrohhrghdprhgtphhtthhopehprghulh hmtghksehkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhes vhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehnphhighhgihhnsehgmhgrih hlrdgtohhmpdhrtghpthhtohepmhhpvgesvghllhgvrhhmrghnrdhiugdrrghupdhrtghp thhtohepghhrvghgkhhhsehlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdhrtghpth htohepsghighgvrghshieslhhinhhuthhrohhnihigrdguvg X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 21 Dec 2025 04:59:09 -0500 (EST) Date: Sun, 21 Dec 2025 18:59:07 +0900 From: Boqun Feng To: Joel Fernandes Cc: Mathieu Desnoyers , 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 , 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 , 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-4-mathieu.desnoyers@efficios.com> <42607ed5-f543-41bd-94da-aa0ee7ec71cd@efficios.com> <6353feeb-c2ab-4ff6-9ea6-04ae5102641d@nvidia.com> <6b27f3c3-47f7-402f-aa6c-b564e3db1d6a@efficios.com> <38d05c17-c28e-4ec1-be30-e77fd7015b5a@nvidia.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: <38d05c17-c28e-4ec1-be30-e77fd7015b5a@nvidia.com> On Fri, Dec 19, 2025 at 05:39:00PM -0500, Joel Fernandes wrote: > > > On 12/19/2025 5:19 PM, Mathieu Desnoyers wrote: > > On 2025-12-19 10:42, Joel Fernandes wrote: > >> > >> IMHO the overflow case is "special" and should not happen often, otherwise > >> things are "bad" anyway. I am not sure if this kind of complexity will be worth > >> it unless we know HP forward-progress is a real problem. Also, since HP acquire > >> will be short lived, are we that likely to not get past a temporary shortage of > >> slots? > > > > Given that we have context switch integration which moves the active > > per-cpu slots to the overflow list, I can see that even not-so-special > > users which get preempted or block regularly with active per-cpu slots > > could theoretically end up preventing HP scan progress. > > Yeah, I see. That's the 'problem' with the preemption design of this patchset. > You always have to move it in and out of overflow list on preemption even when > there is no overflow AFAICS. My idea (which has its own issues) does not require > that on preemption. > > > Providing HP scan progress guarantees is IMO an important aspect to > > consider if we want to ensure the implementation does not cause subtle > > HP scan stall when its amount of use will scale up. > > Sure. But if you didn't have to deal with a list in the 'normal' case (not over > saturated slots case), then it wouldn't be that big a deal. > With PREEPT_HAZPTR, the overflow list will be used if a task gets preempted while using hazptrs, without PREEPT_HAZPTR, the overflow list will be used if there are more than 8 slots used on the CPU (most likely due to task being preempted with a hazptr slot being used). Therefore, if this hazptr design it to have a few users and we want to support that preemptible hazard pointer read-side section, soon or later we need to resolve this scanning racing with readers (in context switches) on overflow list issue. Surely we don't need to have something perfect in day 1, but planning a bit ahead won't hurt ;-) Regards, Boqun > >> Perhaps the forward-progress problem should be rephrased to the following?: If a > >> reader hit an overflow slot, it should probably be able to get a non-overflow > >> slot soon, even if hazard pointer slots are over-subscribed. > > > > Those are two distinct forward progress guarantees, and I think both are > > important: > > > > * Forward progress of HP readers, > > * Forward progress of HP scan. > [..]