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

[Jun Sun <jsun@mvista.com>]

Johannes Stezenbach wrote:
> On Thu, Jul 25, 2002 at 10:06:55AM -0700, Jun Sun wrote:
> 
>>Johannes Stezenbach wrote:
>>
>>>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?
> 

There are probably more than you think.  The popuplar (and notorious) NEC 
VR41xx family fall into this category.  I think at least one or two other 
families of CPUs are like this too.

Jun