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 DC04CC83F1B for ; Wed, 16 Jul 2025 15:33:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6ABF76B00AF; Wed, 16 Jul 2025 11:33:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 65C366B00B0; Wed, 16 Jul 2025 11:33:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 524806B00B1; Wed, 16 Jul 2025 11:33:50 -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 3BF126B00B0 for ; Wed, 16 Jul 2025 11:33:50 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D9D348036C for ; Wed, 16 Jul 2025 15:33:49 +0000 (UTC) X-FDA: 83670522978.21.5CBB1D1 Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) by imf06.hostedemail.com (Postfix) with ESMTP id 904D9180018 for ; Wed, 16 Jul 2025 15:33:47 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fRvwGVYK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.222.178 as permitted sender) smtp.mailfrom=boqun.feng@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752680027; a=rsa-sha256; cv=none; b=n/1H0zPpRyc20qYczOtmLRxTImckMxz5Rf4UV4CNukXoXr4AYaiPfJH81r5WIbXifQT+qb /1ZMP75TcsGkigQvr6XL6BqI6iVNHHq1p75exy2xa3LXentCODsAv7VO7Y7XNLWGe/f8ip wsVgvTeTP0RGp8CCvpn0jUoOvSjaTGY= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fRvwGVYK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.222.178 as permitted sender) smtp.mailfrom=boqun.feng@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752680027; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=jHnbFfh1u32VDfmzatgR36A7Ry3U/16eay9Mf7feuDE=; b=uuwh5hxBTW5etoVaj6e+HEDFDf0MRlloyxY7XcYySdqi1t9pmbDmsZhzvpo2zn3TFBEMoa OOIozpcpMQnj1pFUrFpBoDCJ6m2nuyvTA/Umh51Gx7H1QvdCvVp8uvgPIWpI4zVl+3cIX2 qmxa1sat7EilPBtXf4qvuMnSKIUSZEY= Received: by mail-qk1-f178.google.com with SMTP id af79cd13be357-7e33fa45065so153870285a.1 for ; Wed, 16 Jul 2025 08:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752680026; x=1753284826; darn=kvack.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=jHnbFfh1u32VDfmzatgR36A7Ry3U/16eay9Mf7feuDE=; b=fRvwGVYKLUCr60a2c7jjRWfavt3FCsrGp8RGHW4JbUb4Fh6S2fBFVg3gYTwYr3fReK vFFXxwks0mq1Kk1W6zodGaMTARPDQKk/BhwLdV8gGahoDH5264EDSdyeghHT+6t3eczM p2Rjx+hABk5Wjc1++FQS7vvNfCeOv/w+K4Bqua84yt9yH/vVDsOBuZ0d7l82Mz4vxtII lEZMIwU/7Wcl1XzjVUk4cDKP10aN1k5fJAuOJZkD2aUoZ02ZH/jBflohbGTR8LzzWEFo /r/r0SbyN9Lt3wFs18BLL95ug9hWbmn+lZo9G5AP07bgIJxpzT109wU1500KTFQood7B iDQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752680026; x=1753284826; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jHnbFfh1u32VDfmzatgR36A7Ry3U/16eay9Mf7feuDE=; b=H2JlFz3Nz3xp6PvJ0zxb12F5ELBeSLYLsPFhiL7/X3oU0l/I6kmuH0iPj3RDOHK0CI GBkWIA9Tribi5c5uG46Nw+mVLcCXlzlnrEONWmLxdcvowDSvxY24NgGbOwjRBqgkCecF Fm6X63A2YbCTRbIMoCBB6IDuLWMAZyKfaoR+mY4yyTNHE7hV/C0Q+6xeQEAZhTzphbGf aaazbKE4gTULdzYB6aT56tyGNNk6q92DPhGKN/QhKBr48W/YCwliNLgWrYv/2Bhlgnan gmEPy/S9W6WN6wwyj1tzljz+oJKP1oqV51uZixIByKBg89fJ65XprQshhyuttXQlZiqg Keew== X-Forwarded-Encrypted: i=1; AJvYcCUXV9wARdElUl7Or6sMoaVI7FZjWgP+W6gZhQ+SpU9b110krGWyaiKoHSE9G72sJ589p15iT3GbRA==@kvack.org X-Gm-Message-State: AOJu0Yz4vHpMoBhTrMYs1P0JI3rH1eUgdCb3Ig1L7UW29jCi89NkKZNm mcwTR9Yy6I2f3/OrCkLQAjl9jbc3vV/NFsJD9mbys0aVqlrGH0ujjY41 X-Gm-Gg: ASbGnctbT8qdorD3sT7vWe5t7tE5Pp2E49JqZ71eV1+IrEQ6ZZwKrH3wy8RFdXuEafy QbXiHkOk3IOZzKfO5VEQE5SwXX4pvweZHR+43MU1rNsdVJLt7vvL6KTCYm+6sA2AhvfERsdhgW2 NvfZXi793jYcXxWLABbEBRSHqfw65J2LNFU/f9r87XsmMjqxPIFvQWycGa5dUIk2MTGOLJ9cMpa CRN54Z7KXEJviCQ4ejlEq9guaHFE3mKMFK+qcYEmH5U20CkfUrB/SZvoEMBcRcyDDRAawQ6bXZo xgXd47l+UkwyRBREvQGozRZvcBBhjvkXCNesLPXWvMx7NWXCrXel5cim9Gw/pb/pePgxs1sk3/r M5cjK7sznjwlX5aQvkX/QbUUZLsllLzbO7nMS/vOYcKSJRSKB6PXIB4NcQS1u6Gj1FF1tzQQZIS e1Y7ZbSa+nXO3a X-Google-Smtp-Source: AGHT+IHLL9KhRPo7ww1I8MiIJ3kjrjsG2TfTOMqhCWadQ5DtVvg9UMNuGxcaBW6P62o7IIztNVMbCw== X-Received: by 2002:a05:620a:268c:b0:7df:f84c:7dae with SMTP id af79cd13be357-7e342b6aef3mr377149385a.38.1752680026069; Wed, 16 Jul 2025 08:33:46 -0700 (PDT) Received: from fauth-a2-smtp.messagingengine.com (fauth-a2-smtp.messagingengine.com. [103.168.172.201]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7e2e29468d8sm374600285a.108.2025.07.16.08.33.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Jul 2025 08:33:45 -0700 (PDT) Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfauth.phl.internal (Postfix) with ESMTP id 0267CF40066; Wed, 16 Jul 2025 11:33:45 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-10.internal (MEProxy); Wed, 16 Jul 2025 11:33:45 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdehkedtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeeuohhquhhnucfh vghnghcuoegsohhquhhnrdhfvghnghesghhmrghilhdrtghomheqnecuggftrfgrthhtvg hrnhephfegtdefveeljeeuueeltdevleehfeeludegteekhfehveeuleegkeelkedtjedt necuffhomhgrihhnpehophgvnhhgrhhouhhprdhorhhgpdgsohhothhlihhnrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghoqhhu nhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqieelvdeghedtieegqdduje ejkeehheehvddqsghoqhhunhdrfhgvnhhgpeepghhmrghilhdrtghomhesfhhigihmvgdr nhgrmhgvpdhnsggprhgtphhtthhopedukedpmhhouggvpehsmhhtphhouhhtpdhrtghpth htoheplhhoshhsihhnsehkvghrnhgvlhdrohhrghdprhgtphhtthhopehlvghvhihmihht tghhvghllhdtsehgmhgrihhlrdgtohhmpdhrtghpthhtohepohhjvggurgeskhgvrhhnvg hlrdhorhhgpdhrtghpthhtoheprghlvgigrdhgrgihnhhorhesghhmrghilhdrtghomhdp rhgtphhtthhopehgrghrhiesghgrrhihghhuohdrnhgvthdprhgtphhtthhopegsjhhorh hnfegpghhhsehprhhothhonhhmrghilhdrtghomhdprhgtphhtthhopegrrdhhihhnuggs ohhrgheskhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprghlihgtvghrhihhlhesghhooh hglhgvrdgtohhmpdhrtghpthhtohepthhmghhrohhsshesuhhmihgthhdrvgguuh X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 16 Jul 2025 11:33:44 -0400 (EDT) Date: Wed, 16 Jul 2025 08:33:43 -0700 From: Boqun Feng To: Benno Lossin Cc: Mitchell Levy , Miguel Ojeda , Alex Gaynor , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Andreas Hindborg , Alice Ryhl , Trevor Gross , Andrew Morton , Dennis Zhou , Tejun Heo , Christoph Lameter , Danilo Krummrich , linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 3/5] rust: percpu: add a rust per-CPU variable test Message-ID: References: <20250712-rust-percpu-v2-3-826f2567521b@gmail.com> <68762e19.170a0220.33e203.a0b7@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 904D9180018 X-Stat-Signature: 6wq71ozqag9hui8i1yw67nz7oe3ttsa4 X-Rspam-User: X-HE-Tag: 1752680027-64398 X-HE-Meta: U2FsdGVkX1/vlzPGvpJFYfGBZjXH7UfSxXRsByfZTF0jf5TzDRa8m51t7v+vujlWZvXP+98pd+CB52l3GYxscliAJvy4V9u/SwfunMcUVQ0JRUvrwsNLZ7F0jWaz8mcGIvOrsQaXaTZBzIwUwgfopwsLhQeYmTdvYVNNpkP/K1cbh7hFcD9VxPglda+K/iw0AdoI5KQRvRBzpflSo8T/am2Xzq9+yyuDQMFRQ/BaxXSSBvnjJzyEyVlvaT7jV8srgtfS+i74T9EtpzzA4Eza08W50HXimExmnQejqcH/i42uhxNeWFYSk7NajoXhguUb+QIZL4Gv2G5j6q5FXqbNItok4ijPg5Y2LmWSvlAFgOij4DOpezWcqpWxdUI8QCvI5pmXsJXjnwhThi5cOP6Z4hVIrb+Tx3gb2QSflkUukDRMp5ZBSfeao5/62pgrohdvb+TtT8mW8LNMBMs2XrClP8y0GkZyMHzvBjEGcVKJsXiJpHr/imvQgN8IfrTMKs1Sb/x1JIlpBk6HJbkU4BYB6T6TOhpuZeh+liTtoYm+bht2n9KMr3rPUsdCbH1BiYT+69ECQ+nO4lQ2yJ4Qm46sBmVncwynaW5kYqr8Ttk0UnOwao/nn4d4bX7wmPfmAe+dyON9VIxyFxRXiwGUn8Ele3el89zMH6DtZ3AlWQ3zeqJ0WAIl9s9HmT/nDejeEEl1xdq+zDRXFiWoSKy8F2QzI/jUMLnFNCi+/Dr/i14odwhhMDdIH9muSqLy1TZBU/eXxPhLe36ck/6WzO09dUk59PQzFlfNaPPeBqxHLUyEVZzOEEPiP8/5GJ7vB2FmEcq6DayS91Pw72elwDD8nXK+fEewF7v0MSlDRp1WRcca+q2YwUs0+cAJqySTMKuoSIQGLd9KvqS1xm6r4M0PVyk/+YFGZ+MdhjZUg2/gbQpsAnTyRRChkV1yLvQmZxwGTND46B5Ere6T2AqfYzhov/V h8i/gXMt /y7Fw7RlU54KZ09QuQwSn8bECmyLI/M1wCR5BaK102Kn4OcipIaff9Oi0BASNTFu3s/AhHLeMpIgJNYD97eO5ZqW7dPfW6ZUXgH5A0tngYg73uak7WYOzDVRlF842z97z6KUvKWp+bPIrsV8mhP3TyuR9l/77fNyLsJeVJhqbonvvHjT9qlSxTK9qexXMUHibs2y+xAGXD6einTjgqTDaCbg5/cjSpPmI1ZsMXY9ueeuEJcW64dNFCPLd25VgYC86puCsaMm9qRvxF6TmKOXcezBBW2si1TCAJp/fitfPcE57P6M6uM0Bse6HPH/ZSipciAl3ugFWDiqy4lIu8wgj3GUPCRKQMNoRnT8vNZ5CdN/rLmcKvj9UfckTHl9raUy8HNyYiV9MAtskcpNwRe7tJevqQS8kIv68pO8gkUhiA8hI6S8jf30XgbphcElORh7ptTg3x5tlK6XjMBzBqCSxAFWxPUpb5SwTCBX7bgeFGsmo+6RauFi+qBb+KoRZWmHjwMlB7fzdr+dzog6ABPZccYTJE8YCXtNhn13KhE/JTdmC3nDJB7JDYG0re1vSZw0dkLvHdMCQi7xfxjq09mNVVPg4eO2O9R54KgPx6RyVAWK62LkcUWG9WoAM7XX2j40298pF 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 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/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 safe > >> >> > API, but the unsafe mechanism is probably necessary to look into at > >> >> > first. > >> >> > >> >> 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 implementing > >> > other safe abstraction (e.g. hazard pointers, percpu counters etc) > >> > >> That's fair, but then it should be `pub(crate)`. > >> > > > > 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. > >> >> > >> > > >> > 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. > >> > >> Yeah. But then we should do that before merging :) > >> > > > > 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 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, 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. > "I want to talk about merging this". It might be that I haven't seen the > RFC patch series, because I often mute those. > 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 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. > >> >> > >> >> 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 reference > >> >> 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. > >> > >> But then you need some sort of synchronization? > >> > > > > 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? > It's up to the users obviously, It could be some sort of locking or RCU, it's case by case. > > 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. > 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. Regards, Boqun > --- > Cheers, > Benno