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

[Ingo Molnar]

* Kyle McMartin <kyle at mcmartin.ca> wrote:

> [Sorry about how long it has taken to get to this... I bounced it to
>  parisc-linux too, so hopefully someone else can comment as well.]
> 
> On Wed, Feb 22, 2006 at 10:13:56AM +0100, Ingo Molnar wrote:
> > There's only one complication i can imagine on PARISC: truly atomic 
> > futex_atomic_cmpxchg_inuser() is not possible in any sane way because 
> > any spinlock based cmpxchg exposes itself to userspace locking up the 
> > kernel - no good. [We could in theory do something about it by imposing 
> > some sort of deadline on the maximum time the spinning-on-userspace-lock 
> > can take - but i dont think it's worth the trouble.]
> >
> 
> 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.

	Ingo