On Thu, Oct 23, 2008 at 03:43:58PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2008-10-22 at 17:59 +0200, Ingo Molnar wrote:
> > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> > > Speed up generic mutex implementations.
> > >
> > > - atomic operations which both modify the variable and return
On Wed, 2008-10-22 at 17:59 +0200, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > Speed up generic mutex implementations.
> >
> > - atomic operations which both modify the variable and return something
> > imply
> > full smp memory barriers before and after the memory oper
Nick Piggin <[EMAIL PROTECTED]> wrote:
> Speed up generic mutex implementations.
>
> - atomic operations which both modify the variable and return something imply
> full smp memory barriers before and after the memory operations involved
> (failing atomic_cmpxchg, atomic_add_unless, etc don't
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> Speed up generic mutex implementations.
>
> - atomic operations which both modify the variable and return something imply
> full smp memory barriers before and after the memory operations involved
> (failing atomic_cmpxchg, atomic_add_unless, etc do
On Sun, 2008-10-12 at 07:46 +0200, Nick Piggin wrote:
> Speed up generic mutex implementations.
>
> - atomic operations which both modify the variable and return something imply
> full smp memory barriers before and after the memory operations involved
> (failing atomic_cmpxchg, atomic_add_unl
Speed up generic mutex implementations.
- atomic operations which both modify the variable and return something imply
full smp memory barriers before and after the memory operations involved
(failing atomic_cmpxchg, atomic_add_unless, etc don't imply a barrier because
they don't modify the t
