Re: [PATCH RFC 3/3] rust: percpu: add a rust per-CPU variable test
From: Mitchell Levy
Date: Tue Jan 07 2025 - 18:41:49 EST
On Sun, Jan 05, 2025 at 01:01:43PM +0000, Charalampos Mitrodimas wrote:
> "Christoph Lameter (Ampere)" <cl@xxxxxxxxxx> writes:
>
> > On Thu, 19 Dec 2024, Mitchell Levy wrote:
> >
> >> + let mut native: i64 = 0;
> >> + let mut pcpu: PerCpuRef<i64> = unsafe { unsafe_get_per_cpu_ref!(PERCPU, CpuGuard::new()) };
> >
> > A bit complex.
>
> I agree with this, maybe a helper function would suffise? Something in
> terms of,
> unsafe fn get_per_cpu<T>(var: &PerCpuVariable<T>) -> PerCpuRef<T> {
> unsafe_get_per_cpu_ref!(var, CpuGuard::new())
> }
I'm certainly open to adding such a helper. Is the main concern here the
unwieldy name? Generally, I prefer to keep modifications to global state
(disabling preemption via CpuGuard::new()) as explicit as possible, but
if there's consensus to the contrary, I'm happy to roll it into the
macro/a helper function.
> >
> >> + native += -1;
> >> + *pcpu += -1;
> >> + assert!(native == *pcpu && native == -1);
> >> +
> >> + native += 1;
> >> + *pcpu += 1;
> >> + assert!(native == *pcpu && native == 0);
> >> +
> >
> > That's pretty straightforward..... But is there no symbolic access to the
> > per cpu namespace? How would you access the kernel per cpu variables
> > defined in C?
> >
> > How do you go about using per cpu atomics like
> >
> > this_cpu_inc(nr_dentry_unused);