All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Benno Lossin" <lossin@kernel.org>
To: "Mitchell Levy" <levymitchell0@gmail.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Dennis Zhou" <dennis@kernel.org>, "Tejun Heo" <tj@kernel.org>,
	"Christoph Lameter" <cl@linux.com>,
	"Danilo Krummrich" <dakr@kernel.org>
Cc: <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
Date: Sun, 13 Jul 2025 11:30:31 +0200	[thread overview]
Message-ID: <DBATM1CUS704.28MKE6BIBQB7G@kernel.org> (raw)
In-Reply-To: <20250712-rust-percpu-v2-3-826f2567521b@gmail.com>

On Sat Jul 12, 2025 at 11:31 PM CEST, Mitchell Levy wrote:
> Add a short exercise for Rust's per-CPU variable API, modelled after
> lib/percpu_test.c
>
> Signed-off-by: Mitchell Levy <levymitchell0@gmail.com>
> ---
>  lib/Kconfig.debug       |   9 ++++
>  lib/Makefile            |   1 +
>  lib/percpu_test_rust.rs | 120 ++++++++++++++++++++++++++++++++++++++++++++++++

I don't know if this is the correct place, the code looks much more like
a sample, so why not place it there instead?

>  rust/helpers/percpu.c   |  11 +++++
>  4 files changed, 141 insertions(+)
> diff --git a/lib/percpu_test_rust.rs b/lib/percpu_test_rust.rs
> new file mode 100644
> index 000000000000..a9652e6ece08
> --- /dev/null
> +++ b/lib/percpu_test_rust.rs
> @@ -0,0 +1,120 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//! A simple self test for the rust per-CPU API.
> +
> +use core::ffi::c_void;
> +
> +use kernel::{
> +    bindings::{on_each_cpu, smp_processor_id},
> +    define_per_cpu,
> +    percpu::{cpu_guard::*, *},
> +    pr_info,
> +    prelude::*,
> +    unsafe_get_per_cpu,
> +};
> +
> +module! {
> +    type: PerCpuTestModule,
> +    name: "percpu_test_rust",
> +    author: "Mitchell Levy",
> +    description: "Test code to exercise the Rust Per CPU variable API",
> +    license: "GPL v2",
> +}
> +
> +struct PerCpuTestModule;
> +
> +define_per_cpu!(PERCPU: i64 = 0);
> +define_per_cpu!(UPERCPU: u64 = 0);
> +
> +impl kernel::Module for PerCpuTestModule {
> +    fn init(_module: &'static ThisModule) -> Result<Self, Error> {
> +        pr_info!("rust percpu test start\n");
> +
> +        let mut native: i64 = 0;
> +        // SAFETY: PERCPU is properly defined
> +        let mut pcpu: StaticPerCpu<i64> = unsafe { unsafe_get_per_cpu!(PERCPU) };

I don't understand why we need unsafe here, can't we just create
something specially in the `define_per_cpu` macro that is then confirmed
by the `get_per_cpu!` macro and thus it can be safe?

> +        // SAFETY: We only have one PerCpu that points at PERCPU
> +        unsafe { pcpu.get(CpuGuard::new()) }.with(|val: &mut i64| {

Hmm I also don't like the unsafe part here...

Can't we use the same API that `thread_local!` in the standard library
has:

    https://doc.rust-lang.org/std/macro.thread_local.html

So in this example you would store a `Cell<i64>` instead.

I'm not familiar with per CPU variables, but if you're usually storing
`Copy` types, then this is much better wrt not having unsafe code
everywhere.

If one also often stores `!Copy` types, then we might be able to get
away with `RefCell`, but that's a small runtime overhead -- which is
probably bad given that per cpu variables are most likely used for
performance reasons? In that case the user might just need to store
`UnsafeCell` and use unsafe regardless. (or we invent something
specifically for that case, eg tokens that are statically known to be
unique etc)

---
Cheers,
Benno

> +            pr_info!("The contents of pcpu are {}\n", val);
> +
> +            native += -1;
> +            *val += -1;
> +            pr_info!("Native: {}, *pcpu: {}\n", native, val);
> +            assert!(native == *val && native == -1);
> +
> +            native += 1;
> +            *val += 1;
> +            pr_info!("Native: {}, *pcpu: {}\n", native, val);
> +            assert!(native == *val && native == 0);
> +        });

  reply	other threads:[~2025-07-13  9:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-12 21:31 [PATCH v2 0/5] rust: Add Per-CPU Variable API Mitchell Levy
2025-07-12 21:31 ` [PATCH v2 1/5] rust: percpu: introduce a rust API for per-CPU variables Mitchell Levy
2025-07-12 21:31 ` [PATCH v2 2/5] rust: rust-analyzer: add lib to dirs searched for crates Mitchell Levy
2025-07-12 21:31 ` [PATCH v2 3/5] rust: percpu: add a rust per-CPU variable test Mitchell Levy
2025-07-13  9:30   ` Benno Lossin [this message]
2025-07-15 10:31     ` Mitchell Levy
2025-07-15 11:31       ` Benno Lossin
2025-07-15 14:10         ` Boqun Feng
2025-07-15 15:55           ` Benno Lossin
2025-07-15 16:31             ` Boqun Feng
2025-07-15 17:44               ` Benno Lossin
2025-07-15 21:34                 ` Boqun Feng
2025-07-16 10:32                   ` Benno Lossin
2025-07-16 15:33                     ` Boqun Feng
2025-07-16 17:21                       ` Benno Lossin
2025-07-16 17:52                         ` Boqun Feng
2025-07-16 18:22                           ` Benno Lossin
2025-07-16 15:35                 ` Boqun Feng
2025-07-12 21:31 ` [PATCH v2 4/5] rust: percpu: Add pin-hole optimizations for numerics Mitchell Levy
2025-07-12 21:31 ` [PATCH v2 5/5] rust: percpu: cache per-CPU pointers in the dynamic case Mitchell Levy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DBATM1CUS704.28MKE6BIBQB7G@kernel.org \
    --to=lossin@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=cl@linux.com \
    --cc=dakr@kernel.org \
    --cc=dennis@kernel.org \
    --cc=gary@garyguo.net \
    --cc=levymitchell0@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tj@kernel.org \
    --cc=tmgross@umich.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.