Выполняет ли муфтезы пользовательского пространства профиля профиля?

Резюме: perf lock профиль pthread_mutex?Выполняет ли муфтезы пользовательского пространства профиля профиля?

Детали:

Инструмент perf имеет возможность perf lock. Страница человек говорит:

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.

Но когда я попытался запустить perf lock record я получил ошибку говоря: invalid or unsupported event: 'lock:lock_acquire'. Я посмотрел, и кажется, что ошибка, вероятно, связана с тем, что мое ядро не скомпилировано с CONFIG_LOCKDEP или CONFIG_LOCK_STAT.

Мой вопрос: perf lock сообщить о событиях, связанных с блокировками пользовательского пространства (например, pthread_mutex) или только с помощью блокировок ядра? Меня больше интересует приложение для профилирования, которое в основном выполняется в пользовательском пространстве. Я думал, что этот вариант в perf выглядит интересным, но поскольку я не могу запустить его без компиляции (или получения) нового ядра, я заинтересован в том, чтобы лучше понять, что он делает до того, как я попытаюсь.

источник

2013-06-07 Gabriel Southern

Основная информация: Имеет ли профиль блокировки pthread_mutex?

Резюме: нет, потому что в пользовательском пространстве pthread_mutex нет никакой точки следа.

Согласно исходному файлу tools/perf/builtin-lock.c (http://lxr.free-electrons.com/source/tools/perf/builtin-lock.c#L939) cmd_lock называет __cmd_record, который определяет несколько perf record для точки трассировки (через -e TRACEPOINT_NAME), а также передать параметры -R -m 1024 -c 1 в perf report. Список определенных точек трассировки: 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,.. определяется в trace/events/lock.h. И trace_lock_acquire определен только в kernel/locking/lockdep.c (перепроверьте в дебианской кодовой базе: http://codesearch.debian.net/search?q=trace_lock_acquire). Только CONFIG_LOCKDEP отсутствует ядро согласно kernel/locking/Makefile:. obj-$(CONFIG_LOCKDEP) += lockdep.o (точки трассировки определены безоговорочно в lockdep.c

Согласно https://www.kernel.org/doc/Documentation/trace/tracepoints.txt все точки трассировки являются ядра только, так perf lock не будет профиль пользовательского пространства замки

. Вы можете попробовать отслеживать точки из LTTng, проекта, который объявляет точки трассировки пользовательского пространства (http://lttng.org/ust), но не будет готовой статистики блокировки, а только необработанных данных по точкам трассировки. Также вы должны определить точки трассировки с помощью макроса tracef() (перекомпилируйте pthreads/glibc или попробуйте для создания собственной обертки вокруг pthread).

источник

2014-04-08 01:45:16 osgx

Выполняет ли муфтезы пользовательского пространства профиля профиля?

ответ

Смежные вопросы