Est-ce que perf lock profile mutexes de l’espace utilisateur?

Résumé : Est-ce que perf lock profile pthread_mutex?

Détails :

L’outil perf a une option perf lock . La page de manuel dit:

 You can analyze various lock behaviours and statistics with this perf lock command. 'perf lock record ' records lock events between start and end . 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. 

Mais quand j’ai essayé d’exécuter perf lock record j’ai eu une erreur en disant: invalid or unsupported event: 'lock:lock_acquire' . J’ai regardé et il semble que l’erreur est probablement due au fait que mon kernel n’est pas compilé avec CONFIG_LOCKDEP ou CONFIG_LOCK_STAT .

Ma question est la suivante: est-ce que perf lock rapporte les événements liés aux verrous de l’espace utilisateur (comme pthread_mutex) ou uniquement les verrous du kernel? Je suis plus intéressé par les applications de profilage qui s’exécutent principalement dans l’espace utilisateur. Je pensais que cette option dans perf semblait intéressante, mais comme je ne peux pas l’exécuter sans comstackr (ou obtenir) un nouveau kernel, je suis intéressé à avoir une meilleure idée de ce qu’il fait avant d’essayer.

Résumé: Est-ce que perf lock profile pthread_mutex?

Résumé: non, car aucun sharepoint trace n’est défini dans l’espace utilisateur pthread_mutex.

Selon le fichier source tools/perf/builtin-lock.c ( http://lxr.free-electrons.com/source/tools/perf/builtin-lock.c#L939 ), cmd_lock appelle __cmd_record , qui définit plusieurs points de trace pour perf record (via -e TRACEPOINT_NAME ) et transmettre également les options -R -m 1024 -c 1 pour effectuer le perf report . Liste des points de trace définis: 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,.. est défini dans trace/events/lock.h Et trace_lock_acquire est défini uniquement dans kernel / locking / lockdep.c (revérifier dans le code debian: http://codesearch.debian.net/search?q= trace_lock_acquire ) Seul le fichier CONFIG_LOCKDEP est manquant dans votre kernel en fonction du kernel/locking/Makefile : obj-$(CONFIG_LOCKDEP) += lockdep.o (les points de trace sont définis sans condition dans le lockdep.c .

Selon https://www.kernel.org/doc/Documentation/trace/tracepoints.txt, tous les points de trace sont uniquement basés sur le kernel, ce qui perf lock l’application ne définira pas les verrous de l’espace utilisateur.

Vous pouvez essayer les tracespoints de LTTng, le projet qui déclare les tracespoints de l’espace utilisateur ( http://lttng.org/ust ). Mais il n’y aura pas de statistiques de locking prêtes, mais uniquement des données brutes sur les traces. Vous devez également définir des points de trace avec la macro tracef() (recomstackr pthreads / glibc, ou essayer de créer votre propre wrapper autour de pthread).