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 865B4C83F1B for ; Wed, 16 Jul 2025 10:32:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 27D996B0095; Wed, 16 Jul 2025 06:32:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2552C6B0096; Wed, 16 Jul 2025 06:32:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 192056B0098; Wed, 16 Jul 2025 06:32:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 065956B0095 for ; Wed, 16 Jul 2025 06:32:13 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A091C587E2 for ; Wed, 16 Jul 2025 10:32:12 +0000 (UTC) X-FDA: 83669762904.28.728F5E6 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf05.hostedemail.com (Postfix) with ESMTP id EF087100007 for ; Wed, 16 Jul 2025 10:32:10 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bvyQTHES; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf05.hostedemail.com: domain of lossin@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=lossin@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752661931; a=rsa-sha256; cv=none; b=6hcPlMMeUqhZxXUVFm8z5igL+2iJE7MGAzX0D2IEOAsPsTdok2nhjd/Eq5a+1TrlUsEeVE 5NnYDD1oxFOlnLiurPssTjqemhY2BlSMi7hkCZaKM3ZBC70g5wxdDL23gRATUx/VdMjlrz JGtRjq5zx6SUnw8DJVV7VemaXnQw18E= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bvyQTHES; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf05.hostedemail.com: domain of lossin@kernel.org designates 172.234.252.31 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=1752661931; 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=ljwiQaCtPIBYAevhkpAm1ATld3Dn6eCYmXup1TBmIf4=; b=wKlJ+0U2FxbDgeIGUUgTGUsoV9TUCgZ53TpC7B6tm+tBKL8Ja7FGIowgDpUjbI3kEhpSAp E6HGghp4jUvk1J3fSVbXWGWM5eMAe24ZVMg15Q5sCFSFBugRbmQcqKppvMj+WwvMG9P0qv GkbeHaNDfAZM81zIE5hx+zhQJi+X9ZE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id EDF4145145; Wed, 16 Jul 2025 10:32:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2D3AC4CEF0; Wed, 16 Jul 2025 10:32:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1752661929; bh=4MZ1bakhn2IrJDIzOvrnSvSgvN0+Mb+1IfcHUPCpa+Y=; h=Date:Cc:Subject:From:To:References:In-Reply-To:From; b=bvyQTHESXLlAvBKivoq3pKLQrlaqma74imBvhg2c7VhpXXYKCTvuCpjn3U7ul+S4e dRtU2UQjMYlZIMH/ACKSn4+RDTa1gwitf0B+s/snWu0c7PrsG9Fn3sqUmxx3hDdgkL cKKgFsWEXs64aME/J2OPZNOygILHVpNuAuIIP3tS1RsmtMQOPopjO3uL8qdtqq9Jr4 rxSCjetOzvZ4QQOJnl17nfHburlktXBzc05hje4nqrV1RaWe8EJ08FbREe32fh+fkL HndYM7E2MRWD1y+I/Zelma+KOp9ipCJjazfoXV8Am8g+XUCYxeww3tbbS+ofrSVtvi CAzBKjJ3hTskg== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 16 Jul 2025 12:32:04 +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: <20250712-rust-percpu-v2-0-826f2567521b@gmail.com> <20250712-rust-percpu-v2-3-826f2567521b@gmail.com> <68762e19.170a0220.33e203.a0b7@mx.google.com> In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: EF087100007 X-Stat-Signature: o7cy8aueauxnx9ywjjstyt7s85iaqqob X-Rspam-User: X-HE-Tag: 1752661930-235470 X-HE-Meta: U2FsdGVkX1/O1dLp2UC5iyE/3+ZtWJkYWw/SxBNTperR6kHYToeUJl1RZf1UI6pxySIgK8PEHGkGDHmSjk8IMzCHN+cpERL84qkO1G+IdZc0SzInzfUEvQxeI0i1R3wWYaf3orXaaiGu7BZVy2QxphVFRn1WPI8jhcV5+TP4K5lp/szF1NHWO4TXTuFpzMi+ETixgqr+RrcFZu7KF/u7vcjfLyGRXHX9ddKnACox8Ymr15E93U+/2xqPWeMCgvsibMWJYd0M42ipk7Hi7JyBRZD8iAANsad+Ep8PLwsivv8hJxVXJISC0QQBzqZ5qsKTwC5BQxeWJIo0H6uZOY13cO29X/Sx6uCyFkVv+wWI+Be87nXN4qmqQwkP9N2CFVtuJQloag4g8pee9iz5Tk7xOO6jIquAEHXROqZk2eI/YatB8jFTC64cnnNhZDzyqTYiFs5eNivl79jRcRnVz12fceaQmPygO0FI0x5RUC1aPr9mRFaY4KP6gG5tBC+ei1m8IEOxI2hdaUbj/U4+RG+xnQHN7mmQnE5nifDi0xtpvKUoncfbVFK8ET11kOvfYvYYZZWV4LbqEEya7bl2hANSOaHWobta8cjRlFZfoaYm3MDd0Hcsul87hp2b+6PLorDePeBGdSmaRREf69MCG6UCd9BRjf1M4MZ+fWSAtiJE9639G7Zu/zt+hcg5MEQFujAoeDvpQdQ5jn72H023Vf1YZt0YsomePFNThG/xWkhDsnjZRJAWgfxM1doJLqbhkIVpR/i8Zs8WABHRMNVlXk97yhWhAQ0e3BB2UWk9TsZ1cTsR4VJrLXsWaIRPvFNtgxVJNpQHJfnYYIQN+cvUth0fkSYhoKt5MIs1HUPDHMJb2r8NAl7FtieBFo+tuGvWVTDi87H9Lpasw7oKE0sM9HMGxJa7ASlMo2nU42dxEBZ9iqdCjHxcIvuFQ1+SHrQioUEdcVqlsQbcUE1lBjfFDRY h8A9XXpj NiyyoaVIhRLAyQLAVZKBaZquObQ== 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 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 sys-spe= cific >> >> > unsafe mechanism, right? For example on unix, I think it's using >> >> > pthread_key_t: >> >> > >> >> > https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_= key_create.html >> >> > >> >> > what we are implementing (or wrapping) is the very basic unsafe >> >> > mechanism for percpu here. Surely we can explore the design for a s= afe >> >> > API, but the unsafe mechanism is probably necessary to look into at >> >> > first. >> >>=20 >> >> But this is intended to be used by drivers, right? If so, then we sho= uld >> > >> > Not necessarily only for drivers, we can also use it for implementing >> > other safe abstraction (e.g. hazard pointers, percpu counters etc) >>=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. Only 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 reviewing > here ;-) I understand [PATCH] emails as "I want to merge this" and [RFC PATCH] as "I want to talk about merging this". It might be that I haven't seen the RFC patch series, because I often mute those. >> >> 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!`, but 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 least wit= h >> >> the thread_local-style API. You just need to ensure that no reference >> >> can escape the cpu, so we can make it `!Send` & `!Sync` + rely on kli= nt >> > >> > 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 own >> > 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 operations > themselves or outside the percpu operations. Some cases, the data types > are small enough to fit in atomic data types, and operations are just > load/store/cmpxchg etc, then operations on the current cpu and remote > read will be naturally synchronized. Sometimes extra synchronization is > needed. Sure, so we probably want direct atomics support. What about "extra synchronization"? Is that using locks or RCU or what else? > Keyword find all these cases are `per_cpu_ptr()`: > > https://elixir.bootlin.com/linux/v6.15.6/A/ident/per_cpu_ptr Could you explain to me how to find them? I can either click on one of the files with horrible C preprocessor macros or the auto-completion in the search bar. But that one only shows 3 suggestions `_hyp_sym`, `_nvhe_sym` and `_to_phys` which doesn't really mean much to me. --- Cheers, Benno