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

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

[Kyle McMartin]

[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.

Cheers,
	Kyle M.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

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

[Ingo Molnar]

* Kyle McMartin <kyle@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
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

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

[Carlos O'Donell]

On 4/9/06, Ingo Molnar <mingo@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.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux