Thread (11 messages) 11 messages, 4 authors, 2002-07-26

Re: LL/SC benchmarking [was: Mipsel libc with LL/SC online anywhere?]

From: Johannes Stezenbach <hidden>
Date: 2002-07-25 18:44:35

On Thu, Jul 25, 2002 at 10:06:55AM -0700, Jun Sun wrote:
Johannes Stezenbach wrote:
quoted
sysmips:
       real    1m19.358s
       user    0m28.150s
       sys     0m47.250s

LL/SC emulation:
       real    0m41.246s
       user    0m25.390s
       sys     0m12.240s

branch-likely hack (hm, still without kernel patch...):
       real    0m25.126s
       user    0m17.240s
       sys     0m2.310s
Johannes,

This is great stuff!  Can you explain what are "real", "user", and "sys"? 
Also, what is your initial conclusion?
This are results from simple 'time ./testapp' testing, so its real time
and user/system time reported by wait(4).

Also, I have an interactive gtk+directfb applicaton running. The
difference in response time is quite noticable.

On reason for the big differences is that the Glib-2.0/GObject library
does a lot of locking in its internal type system for every object
created. Other software might not suffer as badly from a slow mutex
implementation.

My conclusion is that it is good for glibc to always use ll/sc,
emulated or not, and for my specific needs I will use the branch-likely
hack. So next I will study kernel source to decide what MAGIC_COOKIE
is best for the branch-likely hack, and where to add 'move k1,$0'
before eret.

OTOH I doubt it's worth it to add the branch-likely hack to
stock glibc. How many people are using Linux/MIPS on embedded
CPU's without LL/SC?


Johannes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help