[parisc-linux] Re: + parisc-add-ptr-compatpatch.patch added to -mm tree

Carlos O'Donell carlos at systemhalted.org
Sun Apr 9 08:09:07 MDT 2006


On 4/9/06, Ingo Molnar <mingo at elte.hu> wrote:
> > Due to a complete lack of useful atomic operations on parisc, the way
> > I envisioned implementing the routines was serializing all futex ops
> > on a kernel spinlock. Since it's a userspace address, we couldn't use
> > an atomic hash unless we found the physical address behind it, so just
> > one spinlock would do... Of course, I'm probably missing something
> > critical here, though.
>
> if userspace doesnt do atomic ops then the solution should be relatively
> easy: make glibc always call into the kernel, and then the kernel-level
> futex.h ops can be implemented in a lockless manner (i.e. not even a
> spinlock is needed) and you'll get (pretty scalable) futex
> functionality. The in-kernel futex hash-bucket spinlocks take care of
> locking.

HPPA has a light-weight kernel syscall that does
atomic-compare-and-swap, and indeed this is what we use for our NPTL
implementation. We can use that *or* call into the kernel for
arbitration. The atomic-compare-and-swap also uses a hash-bucket of
spinlocks on SMP systems. We hash on a virtual address so it scales
nicely. Not forever though. Some analysis to see which is faster
should be done. I think we will always win with the light-weight
syscall.

Cheers,
Carlos.



More information about the parisc-linux mailing list