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 C2740C83F22 for ; Wed, 16 Jul 2025 17:21:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2BC2C6B009E; Wed, 16 Jul 2025 13:21:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 294446B00A3; Wed, 16 Jul 2025 13:21:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A9CB6B00A6; Wed, 16 Jul 2025 13:21:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 072BA6B009E for ; Wed, 16 Jul 2025 13:21:41 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B873116034A for ; Wed, 16 Jul 2025 17:21:40 +0000 (UTC) X-FDA: 83670794760.17.3B4F5B4 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf21.hostedemail.com (Postfix) with ESMTP id 11CB51C0007 for ; Wed, 16 Jul 2025 17:21:38 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=UCfXXjU3; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf21.hostedemail.com: domain of lossin@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=lossin@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752686499; a=rsa-sha256; cv=none; b=plp3QQjiTdgbidmbnsVFuWmuvq2n1V5Wfb9TSCMDuDUEdyDGuS+huEy9uf/h4mMf19UJuA uaVoObed/BjsiJcwh53ZT/OMduy8eVaSz2E7h9n85HpwD9RntwXxb/3csSAjzpXY47e4u6 NXhQOzxHc56B3pozfRt+6QjGj0AOiWs= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=UCfXXjU3; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf21.hostedemail.com: domain of lossin@kernel.org designates 172.105.4.254 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=1752686499; 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=OhMYWzbQe3YV/+cBWhIM0MWG1lv016wzsMtvbdkOqeg=; b=hVyTBPDUrbzS3afWPY16e46Qtr2X7lk+MugvMaDOYS1gPRzEkJrNMNpg5gzrdycDGSmgrL GfcoU8ECe1iaJf5S40mGgItKUFiWY28fKz1FprUPDcrZOFEdWqKqszQcMPJxx/KZK/V2RF CNBCzAQszjLWjeqTnS8kBpnm0wQjPmk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id E2E4A61433; Wed, 16 Jul 2025 17:21:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 38B7DC4CEE7; Wed, 16 Jul 2025 17:21:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1752686497; bh=2negnZkD72TZWe3BsPmibIcM1Vow8UKfserRA3k3YuA=; h=Date:Cc:Subject:From:To:References:In-Reply-To:From; b=UCfXXjU3lbjom+okhpOsljp81vLHkWGlaWmae1qR96mYl372TUjEiuJRLvOBMmYzK h1vGipHbIGGghf3CL8Lfnlvb6bwMbhGpwOLbzYY3LCXya3d1Tjvx1lKnsTAxCan4aY G3hjFk+fLeA+H5LhNOrzVggbfaSZ3jEU9KSXyo2j4qzq7g0bkGe6cE6hyvBX9cLFn6 A51OOAWDIrHGhgzDIr26/6ad0uXdWdcTZ2log3q7a3ASDWgk3Kowgt8et2m9bEeu4H bu/sir6KbdIjZnfaBxe8MraXhTsGLPN8djzl7aa5DO7T7wsSBEUXhZAaE/u3IT1f7y Xt7aLkCkgRwmg== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 16 Jul 2025 19:21:32 +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-3-826f2567521b@gmail.com> <68762e19.170a0220.33e203.a0b7@mx.google.com> In-Reply-To: X-Rspamd-Queue-Id: 11CB51C0007 X-Stat-Signature: bwmdg1h93pjsantx5tg735n5jcz3wje9 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1752686498-181118 X-HE-Meta: U2FsdGVkX19xEFFAaL8IGiA+lHUuzp+UKrGXOkgqdn9oVelH3Eop1xda8R0bsXOyPoL79dtGrkB85fIU9o6KoRU2q1KrHah4CL89pMfU91pLNV3w1BFR7ZxMcMzGHAoRRjKVJ2/h9BYyoKZMj8onYdMA6hvFWjxH77EOuoyyia5Ni7VtCy5sr+N84gfli7m1K+eUgZth9OZmNfJuqwNkoYOqVI5MUFMjUGXmVXF4aeaHpSRErpw8/2WtaT9A5U71iiv6bIXBbzIs7Ig3/hftv1gGbO1saWcDMROh4vObRwUEqbcPXjn1JY4izV7RsU63x0szcxmp+qVOwL0Y0OSe0y1ym/aoeZmAn2fF/RKZwpT54SxVPI5dQ0upyTvd0buTG/I8IysamB6lc3YxyEbZ+fDTAzqUXjnK6fby1w5S/KXGP+4uqy0jZvnnLPqHvo4Bhr0NsndtPDryDIoumPAO+m2jSKM8zOFLb0+2h0nw1D4lXIqEqAxxn44fqdU09vAE2OyYKSBz6PK5y03Fa+P0Or/ajvB4UIs4KiFqDjrAsjYUKZDQ8bnKVKAoCNIdtuy4pBlyb6rxixyu2/cCLMwFx0995PjqbYX89mlNG5VRCmG/CXvNRrd2uhI/VZ/ch2XZbDXGXj5uKvZ30DKWTlnRe9c9MH+fc8YaOiCmIxw7S7oItfUMF5MvcpACSDNIWmM5+8vbDp5rZj7V1liGsvnJlJGH75Vplimc24utgEIUpuTtnITIMLPBJXgVhVE9qTaAGkh4fJvvzfu/UjtW92GcaX/zBPgG58PiR5Ln+9d2asyVYVf7WDR72YkzLN77D9JrKRhM9zRNqJSYADFGYaeK/e/fX6Z/AtuhRPJi8y8RiLxsTpc6pkjq6zZ7YmDPBLYzBOnWBZX2bcilbShtaKGlLRPwAarz4z5WGJ7gFKHg5V0eNriRAXN/Ru132q11srQjkA1WXyiKM12DTXIlFHA td3EZcBV boaMBjjWMdRdXH/vHqZsrNwOSykLal2XM+SNg4vsJsKsFhPaTATbJqCJVOCkgAEnaLik4Cu8VOpgb+2+EkeLzs5df656RIhVI0ooac+uArF/sguie3s9r3ncY8SK8ypt3Xz+IIECZxmMTEvONmNNVYd6tIE34KXpEkhWDaacCiv0LBJbXLi5ictEd5lyXc3ZAF4NpDXL8AdzrG7nw90UFAjfpUVr4lpGgajyadBFBml9ls9a1jchMe9VjCIYxSAzi9AfK7slQu85GSD/8sVoGRBiNIOkwaNAPAQIBL/O1tG9k4T2vppeiYbPXqsiyEnKd8dwYE0wC60O/6iVqveBqa1Eidp51pvLsCZQ41UndRTtqPAA8UjKYlY/CFqdOhBq2SqDSG7e8HeRCYIzVt4Vh5ba2+cvsaiUD5ngZ46q97LJK0FoJRNWxGiGggWkej7NOX9DawBbS3n7yVOE= 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 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 sys-= specific >> >> >> > unsafe mechanism, right? For example on unix, I think it's using >> >> >> > pthread_key_t: >> >> >> > >> >> >> > https://pubs.opengroup.org/onlinepubs/009695399/functions/pthre= ad_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 safe >> >> >> > 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 = should >> >> > >> >> > Not necessarily only for drivers, we can also use it for implementi= ng >> >> > 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 f= all >> >> >> back to unsafe if it isn't possible. >> >> >>=20 >> >> > >> >> > All I'm saying is instead of figuring out a safe abstraction at fir= st, >> >> > we should probably focus on identifying how to implement it and whi= ch >> >> > 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 reviewi= ng >> > 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, Yeah that is true, but it at least shows the intention :) > 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. That is true, I do usually read the titles of RFC patches though and sometimes take a look eg your atomics series. >> "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 the > difference between [PATCH] and [RFC PATCH] if you ignore one of them ;-) 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. >> >> >> 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 = with >> >> >> the thread_local-style API. You just need to ensure that no refere= nce >> >> >> 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 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 operatio= ns >> > themselves or outside the percpu operations. Some cases, the data type= s >> > 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 i= s >> > 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 RCU, > it's case by case. Makes sense, what do you need in the VMS driver? >> > Keyword find all these cases are `per_cpu_ptr()`: >> > >> > https://elixir.bootlin.com/linux/v6.15.6/A/ident/per_cpu_ptr >>=20 >> 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. >>=20 > > You need to find the usage of `per_cpu_ptr()`, which is a function that > gives you a pointer to a percpu variable on the other CPU, and then > that's usually the case where a "remote" read of percpu variable > happens. Ahh gotcha, I thought you pointed me to some definitions of operations on percpu pointers. --- Cheers, Benno