Re: atomic-up.h speedup : compared with irq disable/enable

Hi Sergei,

* Sergei Shtylyov ([email protected]) wrote:
> Hello.
> 
> Mathieu Desnoyers wrote:
> >Some more information about the non LOCKed atomic ops that I now use on 
> >SMP :
> 
> >A test ran on a 3GHz Pentium 4 shows that (20000 loops) :
> 
> >irq save/restore pair      210.60 ns
> >
> >cmpxchg                     49.46 ns
> >    (76 % speedup)
> >cmpxchg-up (no lock prefix)  9.00 ns
> >    (95 % speedup)
> 
> >Does anyone still believe that cli()/sti() is faster ? :)
> 
>    Alas, it's not so for RISCs anyway -- they don't have RMW type 
> instructions with memory desctinations,

RMW in a single instruction, no, but what about PowerPC lwarx and stwcx
instructions, which watches the memory for modification and permits a cmpxchg
in 5 instructions ?

> so you still have to use cli/sti (or locking).

I made atomic-up.h headers for i386, x86_64 and powerpc architectures. Those
were the ones where the behavior changed between SMP and UP. I didn't see any
interesting "easy" optimization for MIPS and ARM though.

For PowerPC, I removed the LWSYNC_ON_SMP (lwsync or sync) and ISYNC_ON_SMP 
(isync) macros, which must be there to insure proper ordering which is
unneeded in my case.

quoting Paul McKenney, http://www.linuxjournal.com/article/8212

"sync causes all preceding instructions, not only memory references,
to appear to have completed before any subsequent operations are
started. This instruction, therefore, is quite expensive."

"lwsync, or lightweight sync, orders loads with respect to subsequent
loads and stores, and it also orders stores. However, it does not order
stores with respect to subsequent loads. Interestingly enough, the
lwsync instruction enforces the same ordering as does the zSeries and,
coincidentally, the SPARC TSO."

"isync forces all preceding instructions to appear to have completed
before any subsequent instructions start execution. This means that
the preceding instructions must have progressed far enough that any
traps they might generate either have happened or are guaranteed not to
happen. Furthermore, any side effects of these instructions-for example,
page-table changes-are seen by the subsequent instructions."


>   I guess we also need to benchmark this on some RISCs like ARM/MIPS/PPC...
> 

Please feel free to test it on PowerPC. The test modules are available (with
a Makefile) at http://ltt.polymtl.ca/svn/tests/kernel/

Makefile
test-irqloop.c
test-cmpxchg-nolock.c (currently needs atomic-up.h from LTTng 0.6.29)
test-cmpxchg.c

Regards,

Mathieu

OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68