Czy przestrzeń użytkownika profilu blokowania perf zablokuje się?

Question

Podsumowanie: Czy perf lock profil pthread_mutex?

Szczegóły:

Narzędzie perf posiada opcję perf lock. Strona człowiek mówi:

You can analyze various lock behaviours and statistics with this perf lock command. 
    'perf lock record <command>' records lock events 
    between start and end <command>. And this command 
    produces the file "perf.data" which contains tracing 
    results of lock events. 

    'perf lock trace' shows raw lock events. 

    'perf lock report' reports statistical data. 

Ale kiedy próbowałem działa perf lock record mam błąd mówiąc: invalid or unsupported event: 'lock:lock_acquire'. Wyglądałem i wygląda na to, że błąd prawdopodobnie wynika z tego, że moje jądro nie jest skompilowane z CONFIG_LOCKDEP lub CONFIG_LOCK_STAT.

Moje pytanie brzmi: czy perf lock zgłasza zdarzenia związane z blokadami przestrzeni użytkownika (np. Pthread_mutex) lub tylko blokadami jądra? Bardziej interesuje mnie profilowanie aplikacji, które najczęściej działają w przestrzeni użytkownika. Myślałem, że ta opcja w perf wygląda interesująco, ale ponieważ nie mogę jej uruchomić bez kompilowania (lub otrzymywania) nowego jądra, jestem zainteresowany lepszym pomysłem na to, co robi, zanim spróbuję.

Answer 1

Podsumowanie: Czy perf zablokować profil pthread_mutex?

Podsumowanie: nie, ponieważ nie ma żadnego punktu tracepoint zdefiniowanego w przestrzeni użytkownika pthread_mutex.

Zgodnie z pliku źródłowego tools/perf/builtin-lock.c (http://lxr.free-electrons.com/source/tools/perf/builtin-lock.c#L939) cmd_lock nazywa __cmd_record, która definiuje kilka tracepoints dla perf record (przez -e TRACEPOINT_NAME), a także podać opcje -R -m 1024 -c 1 do perf report. Lista tracepoints zdefiniowane: lock_tracepoints:

842 static const struct perf_evsel_str_handler lock_tracepoints[] = { 
843   { "lock:lock_acquire", perf_evsel__process_lock_acquire, }, /* CONFIG_LOCKDEP */ 
844   { "lock:lock_acquired", perf_evsel__process_lock_acquired, }, /* CONFIG_LOCKDEP, CONFIG_LOCK_STAT */ 
845   { "lock:lock_contended", perf_evsel__process_lock_contended, }, /* CONFIG_LOCKDEP, CONFIG_LOCK_STAT */ 
846   { "lock:lock_release", perf_evsel__process_lock_release, }, /* CONFIG_LOCKDEP */ 
847 }; 

TRACE_EVENT(lock_acquire,.. jest zdefiniowana w trace/events/lock.h. I trace_lock_acquire jest zdefiniowany tylko w jądrze/locking/lockdep.c (sprawdź ponownie w kodzie debian: http://codesearch.debian.net/search?q=trace_lock_acquire). Tylko CONFIG_LOCKDEP brakuje jądrze według kernel/locking/Makefile. obj-$(CONFIG_LOCKDEP) += lockdep.o (tracepoints zdefiniowane są bezwarunkowo w lockdep.c

Według https://www.kernel.org/doc/Documentation/trace/tracepoints.txt wszystkie tracepoints są jądra tylko, więc perf lock nie będzie profil zamki przestrzeni użytkownika

. Możesz wypróbować punkty tracone z LTTng, projektu, który deklaruje punkty śledzenia przestrzeni użytkownika (http://lttng.org/ust), ale nie będzie gotowych statystyk blokad, tylko surowe dane na punktach kontrolnych.Należy również zdefiniować punkty kontrolne z makro tracef() (rekompiluj pthreads/glibc lub spróbuj aby stworzyć własne opakowanie wokół pthread)