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 65E69C83F1B for ; Wed, 16 Jul 2025 18:22:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C7E1E6B0096; Wed, 16 Jul 2025 14:22:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C2DF16B009A; Wed, 16 Jul 2025 14:22:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF6476B009E; Wed, 16 Jul 2025 14:22:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 9EE2D6B0096 for ; Wed, 16 Jul 2025 14:22:38 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 6E54B1604F4 for ; Wed, 16 Jul 2025 18:22:38 +0000 (UTC) X-FDA: 83670948396.01.0C338F4 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf15.hostedemail.com (Postfix) with ESMTP id 9B3F7A0002 for ; Wed, 16 Jul 2025 18:22:36 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=tIuvixBK; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf15.hostedemail.com: domain of lossin@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=lossin@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752690156; a=rsa-sha256; cv=none; b=jfWvYEHIjs/x0uot60zZ1ZEY2G247mwkZBbDc2e7EATlVeMQHS0pBKWL6KuDxsfO0e0Pjm MQugTPAi3T3nk01q4oa1ShuavV9d1SkTqo9qZdeyyh1+z3LGeHH1k8hmR4SLuuMLY9Wi4/ GgUgGsQntKoB31kKVI2ybIyAG5o4eE4= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=tIuvixBK; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf15.hostedemail.com: domain of lossin@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=lossin@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752690156; 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=ijV2YK9UkywvhBfqjVomRAxZLwlCSrGbjouNdBPBVK0=; b=JDnoA4qy6/BACUVgr7l1i10Llpv17quwiy+BxB2uMkWU7fKG+NVW8fwOA1VHyAc/umsbuo coQzrqUmGi3zlsO5lXIeF0I0C+r72HVQBLDPEOW6iqJMEtpp7YSuovsuHNqg+Qi83U+0wo tLqg/IkVIDhon5feXegM7hw77G2seGU= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id A9C225C5812; Wed, 16 Jul 2025 18:22:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0B324C4CEF5; Wed, 16 Jul 2025 18:22:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1752690155; bh=OeN+yejltezB0oHCvVEcUaFL4aGPQNlK36DE8/EOhCM=; h=Date:Cc:Subject:From:To:References:In-Reply-To:From; b=tIuvixBKvt01pdq5U/fT9qlDLFCiTTfA+FTWSfwDLnEZX39iX/+1NWnADEFFr3q0F Alzef/ZpSKZo+smrTOx82AmeXYGIbViLpwDwhxXYowwEyAPShmRDNUjPF+wqQzrBwE EZQocoYx2mZ7bdUHPWXFF5psb5ij5bb5VR7O528HMmyvY+WqV4S8VJ5adOf1GybLW7 /FZ5zkmg9aMXmM5B5D3NUYWrzRKOHTYxgEdWrFbPwBetJopEydrlxQ8FBkI9/zazcr 2Owi2whXSHxEyPmZS1SQX+TLZW393t2718FjSL97EkKARJlI52M68T4dyP0iO1XfJh p7+zJ4W3ZtTFw== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 16 Jul 2025 20:22:30 +0200 Message-Id: Cc: "Mitchell Levy" , "Miguel Ojeda" , "Alex Gaynor" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Andreas Hindborg" , "Alice Ryhl" , "Trevor Gross" , "Andrew Morton" , "Dennis Zhou" , "Tejun Heo" , "Christoph Lameter" , "Danilo Krummrich" , , , Subject: Re: [PATCH v2 3/5] rust: percpu: add a rust per-CPU variable test From: "Benno Lossin" To: "Boqun Feng" X-Mailer: aerc 0.20.1 References: <68762e19.170a0220.33e203.a0b7@mx.google.com> In-Reply-To: X-Stat-Signature: fracydzkpqzz3axfemugd1hahbxewfs4 X-Rspam-User: X-Rspamd-Queue-Id: 9B3F7A0002 X-Rspamd-Server: rspam02 X-HE-Tag: 1752690156-380120 X-HE-Meta: U2FsdGVkX19fHxJ7Nh6IrHMS4YR/RlVw4qtSUYZM/VMiUh98HMo2DdXc8824IOrSWPPViLPGgJ16Z4K/IDROuzmQ2IAxqQOrCbjJJ92G7LqLlgSeVW9wr+KzPmSm8JVBhLW58u+8FjfTQwqeX/su4UVZc7Nd3FOadib/6fQ58vcsZdW6Ci6k9hIMBeND1c3AuXzVifVEKGXEmdIGLtWBz4eZYd8tXc5Pl9cVhpDoy5Qcy63keTkIo38g/5XuOoaSZW9Vgp/d+DFIqxCR+FOKI0hJQmgOZrfC1hnVDlzxVo77zLD5ywlALAdtYQOV+yhjjFOTjZg12wlEAlTfDdteLWoxwbt3fn9asJJ+9MJ3tbdJF7hMSv82WQlAg5AvVfMEUwHxNvhP+SE9QqKAj6IY50KT6q5YA2gFZH/iwSCOF6XH1V/qq8O1GzhXLEEWVINI3zCb2UzZpbeBiG9S6EdiClVe23ceID842xsHap1cDt8CFHYcM8Qz5mPVAMJE217fpb8pIa2auyB/MfkT/EWv7af/j/ZsuTmVCd2bVavFb0pSkWyb6Wytm0jM1sZ7HsrqwvQImLQ0o8juXVDmuqTE6/llonixVAcFlTxwK730yYaAtcIyqT3A3HFUGIWkBjZwnUZVLij2qyJG2UW7ySkr7oB/XCHaiVHHFR84lQoITukpmG2MsCOpoYCYYNMGyEuQ5s2OHAcHdW+NmRrImS+va3BRrnEnCCeFrw3oaPs7I6xBS6Fjcvpd5VETgcXM/k/Wsg6T7upTBXlQXCLtst/BGymzgqX2wzS6EF+N6Eku6CcD3t6hlyhsyAFHJIDVWRSJjDToeZtovQNgdbP+zbFoTk5PiBr8XDWqUWRLKhgoAI1N0Sa+mVX3w+RuAPRN7tXZxHdtuIrfhqckpC/nAmXsGOEFPk5b1DZqOo46hdSOdSqZ3ocOj6NHOi2G2TT0rOQCd5TF/p0J5Ce1OPgtVPP BndNFY54 yT65qXx3ohJHlU6aEOa+gq5zOI8IcacxDuoo/jvmt35RI1zzXt1uZOht/EvHqLEk2PsTXRudY3moF/rry2ffo7QsLCqlRPlgkOcsJFD1oCharvKycB5uBWEu5B4I0UI4qVeLIyoo5/oCxKfE5DU8MiyrkHfb/y8eYWTFl5+fV00xYsyeBbg6qNHxKhvcBBFGZ6eQUjhF7s5ma78aFohwsKKMyoeVdLSYSPnWQJ8GfktaT5LwgL9cqcIxkXztl+wc3yRDNUk6rLXR47UNe2pX1zM5h4WPWPXs3oVScYN+kFKMqIa12iVrIcI4n3qYkZ73EQmMi8Qr3DFQEYtK08FHtwrAvrEHD7qJr8Rc10Dzq/hLdV6A= 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 Wed Jul 16, 2025 at 7:52 PM CEST, Boqun Feng wrote: > On Wed, Jul 16, 2025 at 07:21:32PM +0200, Benno Lossin wrote: >> On Wed Jul 16, 2025 at 5:33 PM CEST, Boqun Feng wrote: >> > On Wed, Jul 16, 2025 at 12:32:04PM +0200, Benno Lossin wrote: >> >> On Tue Jul 15, 2025 at 11:34 PM CEST, Boqun Feng wrote: >> >> > On Tue, Jul 15, 2025 at 07:44:01PM +0200, Benno Lossin wrote: >> >> > [...] >> >> >> >> > >> >> >> >> > First of all, `thread_local!` has to be implemented by some s= ys-specific >> >> >> >> > unsafe mechanism, right? For example on unix, I think it's us= ing >> >> >> >> > pthread_key_t: >> >> >> >> > >> >> >> >> > https://pubs.opengroup.org/onlinepubs/009695399/functions/pt= hread_key_create.html >> >> >> >> > >> >> >> >> > what we are implementing (or wrapping) is the very basic unsa= fe >> >> >> >> > mechanism for percpu here. Surely we can explore the design f= or a safe >> >> >> >> > API, but the unsafe mechanism is probably necessary to look i= nto at >> >> >> >> > first. >> >> >> >>=20 >> >> >> >> But this is intended to be used by drivers, right? If so, then = we should >> >> >> > >> >> >> > Not necessarily only for drivers, we can also use it for impleme= nting >> >> >> > other safe abstraction (e.g. hazard pointers, percpu counters et= c) >> >> >>=20 >> >> >> That's fair, but then it should be `pub(crate)`. >> >> >>=20 >> >> > >> >> > Fine by me, but please see below. >> >> > >> >> >> >> do our usual due diligence and work out a safe abstraction. Onl= y fall >> >> >> >> back to unsafe if it isn't possible. >> >> >> >>=20 >> >> >> > >> >> >> > All I'm saying is instead of figuring out a safe abstraction at = first, >> >> >> > we should probably focus on identifying how to implement it and = which >> >> >> > part is really unsafe and the safety requirement for that. >> >> >>=20 >> >> >> Yeah. But then we should do that before merging :) >> >> >>=20 >> >> > >> >> > Well, who's talknig about merging? ;-) I thought we just began revi= ewing >> >> > here ;-) >> >>=20 >> >> I understand [PATCH] emails as "I want to merge this" and [RFC PATCH]= as >> > >> > But it doesn't mean "merge as it is", right? I don't think either I or >> > Mitchell implied that, I'm surprised that you had to mention that, >>=20 >> Yeah that is true, but it at least shows the intention :) >>=20 >> > also based on "I often mute those" below, making it "[PATCH]" seems to >> > be a practical way to get more attention if one wants to get some >> > reviews. >>=20 >> That is true, I do usually read the titles of RFC patches though and >> sometimes take a look eg your atomics series. >>=20 >> >> "I want to talk about merging this". It might be that I haven't seen = the >> >> RFC patch series, because I often mute those. >> >>=20 >> > >> > Well, then you cannot blame people to move from "RFC PATCH" to "PATCH" >> > stage for more reviews, right? And you cannot make rules about what th= e >> > difference between [PATCH] and [RFC PATCH] if you ignore one of them ;= -) >>=20 >> I'm not trying to blame anyone. I saw a lot of unsafe in the example and >> thought "we can do better" and since I haven't heard any sufficient >> arguments showing that it's impossible to improve, we should do some >> design work. >>=20 > > I agree with you, and I like what you're proposing, but I think design > work can be done at "PATCH" stage, right? And sometimes, it's also OK to > do some design work even at some version like "v12" ;-) Yeah of course. The thing is just that nobody asked why there was unsafe and thus I got the impression that people thought this would be a good abstraction for percpu. (don't take from this that it's bad :) > Also I want to see more forward-progress actions about the design work > improvement. For example, we can examine every case that makes > unsafe_get_per_cpu!() unsafe, and see if we can improve that by typing > or something else. We always can "do better", but the important part is > how to get there ;-) Yeah that would be a starting point :) >> >> >> >> I'm not familiar with percpu, but from the name I assumed that = it's >> >> >> >> "just a variable for each cpu" so similar to `thread_local!`, b= ut it's >> >> >> >> bound to the specific cpu instead of the thread. >> >> >> >>=20 >> >> >> >> That in my mind should be rather easy to support in Rust at lea= st with >> >> >> >> the thread_local-style API. You just need to ensure that no ref= erence >> >> >> >> can escape the cpu, so we can make it `!Send` & `!Sync` + rely = on klint >> >> >> > >> >> >> > Not really, in kernel, we have plenty of use cases that we read = the >> >> >> > other CPU's percpu variables. For example, each CPU keeps it's o= wn >> >> >> > counter and we sum them other in another CPU. >> >> >>=20 >> >> >> But then you need some sort of synchronization? >> >> >>=20 >> >> > >> >> > Right, but the synchronization can exist either in the percpu opera= tions >> >> > themselves or outside the percpu operations. Some cases, the data t= ypes >> >> > are small enough to fit in atomic data types, and operations are ju= st >> >> > load/store/cmpxchg etc, then operations on the current cpu and remo= te >> >> > read will be naturally synchronized. Sometimes extra synchronizatio= n is >> >> > needed. >> >>=20 >> >> Sure, so we probably want direct atomics support. What about "extra >> >> synchronization"? Is that using locks or RCU or what else? >> >>=20 >> > >> > It's up to the users obviously, It could be some sort of locking or RC= U, >> > it's case by case. >>=20 >> Makes sense, what do you need in the VMS driver? >>=20 > > In VMBus driver, it's actually isolate, i.e. each CPU only access it's > own work_struct, so synchronization between CPUs is not needed. I see, so we could either just start out with no sync support or -- which I would prefer -- get a list of the most common use-cases and implement those too (or at least design the first part compatibly with further extensions). --- Cheers, Benno