Re: [PATCH RFC 3/3] rust: percpu: add a rust per-CPU variable test

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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);




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux