Re: PThread profiling

[Daniel Tralamazza <tralamazza at gmail dot com>]

On Mon, Feb 23, 2009 at 9:17 PM, Josh Stone <jistone@redhat.com> wrote:
> Daniel Tralamazza wrote:
>>
>> I even did a tapset for most pthread functions inside NPTL
>> ('probe pthread.create').
>
> I think such a tapset would have general interest, even with the slower
> uprobe version. ?You could define the tapset to work with both the base
> glibc and your patched version:
>
> probe pthread.create = process(...).mark(...)!,
> ? ? ? ? ? ? ? ? ? ? ? process(...).function(...)
> { ... }

I uploaded a draft of the unified tapset (uprobes + static)
http://daniel.tralamazza.com/pub/pthread_tapset.stp
Thanks for the tips ;)

>
>> It worked fine, but the overhead was causing measurements errors
>> (too slow == higher contention probability). It was clear that I
>> had to use static markers, all I had to do was patch glibc/nptl
>> and voila.
>
> Can you share performance numbers on this? ?I'd like to see the comparison
> of unprobed, function uprobes, and static markers...

I ran 2 web browsers benchmarks on firefox
Spider: http://www2.webkit.org/perf/sunspider-0.9/sunspider-driver.html
V8: http://v8.googlecode.com/svn/data/benchmarks/v3/run.html

                  baseline (no stap)            uprobes
     static markers
spider         2080.4ms +/- 13.3%        couldn't complete
20001.3ms +/- 9.2%
V8              312                                55.2
            75.8

The results are particularly bad on all string functions in spider (up
to 40x overhead).
I am trying to get a proper machine to run these experiments and oprofile it.

>
> Josh
>
>


-- 
Daniel Tralamazza
EPFL IC IIF DSLAB
INN-331