Perf Precise Call-Graph Отчет - PullRequest
       110

Perf Precise Call-Graph Отчет

2 голосов
/ 19 апреля 2020

Последние процессоры Intel предоставляют аппаратную функцию (также известную как Precise Event-Based Sampling (PEBS)) для доступа к точной информации о состоянии ЦП для некоторых выбранных событий ЦП (например, e). Вот выдержка из Руководства разработчика программного обеспечения Intel 64 и IA-32: Том 3 :

18.15.7 Выборка на основе событий процессора (PEBS)

Механизм хранилища отладки (DS) в процессорах на основе микроархитектуры Intel NetBurst позволяет собирать два типа информации для использования в программах отладки и настройки: записи PEBS и записи BTS.

На основе Chapter 17 из той же ссылки формат DS для архитектуры x86-64 выглядит следующим образом: enter image description here BTS Buffer записывает последние N выполненные ветви (N зависит от микроархитектуры), в то время как PEBS Buffer записывает следующие регистры: enter image description here IIU C, устанавливается счетчик, и каждое вхождение события (e) увеличивает свое значение. Когда счетчик переполняется, запись добавляется в оба этих буфера. Наконец, когда эти буферы достигают определенного размера (BTS Absolute Maximum и PEBS Absolute Maximum), генерируется прерывание и содержимое двух буферов сбрасывается на диск. Это будет происходить периодически. Кажется, что данные --call-graph dwarf backtrace также извлекаются в том же обработчике, верно?

1) Означает ли это, что состояния LBR и PEBS (--call-graph --lbr), совершенно сопоставлять вместе?

2) Как насчет вывода --call-graph dwarf, который не является частью PEBS (как это очевидно в приведенной выше ссылке)? (Некоторые RIP/RSP s не соответствуют обратному следу)

Точно, вот LKML Thread , где Milian Wolff показывает, что второй вопрос есть, NO . Но я не до конца понимаю причину?

Ответ на первый вопрос также NO (выражается Andi Kleen в последних сообщениях цепочки ), чего я совсем не понимаю.

3) Значит ли это, что вся информация о графе вызовов DWARF полностью повреждена?

Вышеуказанная тема не показывает это, и в моих экспериментах я не вижу никаких RIP, не соответствующих обратному следу. Другими словами, могу ли я доверять большинству следов?

Я не предпочитаю метод LBR, который сам по себе может быть неточным. Это также ограничено в размере следа. Хотя здесь - это патч для преодоления проблемы с размером. Но это недавно и может быть поддельным.


ОБНОВЛЕНИЕ:

  • Как можно заставить Perf хранить только одну запись в PEBS Buffer? Возможно ли форсировать эту конфигурацию только косвенно, например, когда требуется информация графа вызовов для события PEBS?

1 Ответ

2 голосов
/ 19 апреля 2020

1) В разделе руководства, которое вы цитировали, говорится о BTS, а не о LBR: это не одно и то же. Позже в том же потоке , который вы цитировали, Энди Клин, кажется, указывает, что время привязки LBR на самом деле является моментом PMI (прерывания, которое запускает обработчик), а не моментом PEBS. Поэтому я думаю, что у всех трех стековых подходов есть одна и та же проблема.

2) Захваты стека DWARF точно не соответствуют записи PEBS. Событие PEBS записывается оборудованием во время выполнения, и только спустя некоторое время ЦП прерывается, и в этот момент стек разматывается. Если буфер PEBS сконфигурирован для хранения только одной записи, эти две вещи должны быть по крайней мере close , и если вам повезет, IP-адрес PEBS будет в той же функции , то есть все еще на вершине стека, когда запускается обработчик. В этом случае стек в основном правильный. Так как perf показывает фактический IP-адрес PEBS сверху, а также кадры под кадром из захвата, в этом случае это работает.

3) Если вам не повезет, функция будет иметь изменился между захватом PEBS и запущенным обработчиком. В этом случае вы получаете стек Франкенса, который не имеет смысла: функция top может не вызываться из функции second from the top (или чего-то еще). Он не полностью поврежден: просто все, кроме верхнего кадра, происходит из точки после захвата стека PEBS, а верхний кадр - из PEBS, или что-то в этом роде. Это относится и к --call-graph fp по тем же причинам.

Скорее всего, вы никогда не видели неверный IP, потому что perf показывает IP из образца PEBS (это тема всей этой цепочки). Я думаю, что если вы посмотрите на необработанный пример, вы увидите как IP-адрес PEBS, так и IP-адрес обработчика, и вы увидите, что они обычно не совпадают.

В целом, вы можете доверять обратным следам в течение "времени" Профилирование "или" цикл ", поскольку они в некотором смысле являются точным представлением выборки времени выполнения: просто они не соответствуют моменту PEBS, но некоторое время спустя (но почему это позднее время хуже, чем время PEBS) , По сути, для такого типа профилирования вам вообще не нужен PEBS.

Если вы используете событие другого типа и хотите получить детальный отчет о том, где произошло событие, это то, чем является PEBS. за. Вам часто не требуется трассировка стека: достаточно только верхнего кадра. Если вам нужны стековые трассировки, используйте их, но знайте, что они появляются позже, или используйте --lbr (if that works).

...