Почему perf stat показывает "stalled-cycles-backend" как <not supported>?

Запуск perf stat ls показывает это:

Performance counter stats for 'ls':

          1.388670 task-clock                #    0.067 CPUs utilized          
                 2 context-switches          #    0.001 M/sec                  
                 0 cpu-migrations            #    0.000 K/sec                  
               266 page-faults               #    0.192 M/sec                  
           3515391 cycles                    #    2.531 GHz                    
           2096636 stalled-cycles-frontend   #   59.64% frontend cycles idle   
   <not supported> stalled-cycles-backend  
           2927468 instructions              #    0.83  insns per cycle        
                                             #    0.72  stalled cycles per insn
            615636 branches                  #  443.328 M/sec                  
             22172 branch-misses             #    3.60% of all branches        

       0.020657192 seconds time elapsed

Почему задержка-циклы-бэкенд отображается как "не поддерживается"? Какое программное обеспечение, аппаратное обеспечение, ядро или программное обеспечение для пользовательского пространства мне нужно, чтобы увидеть это значение?

В настоящее время это делается на RHEL с Linux 3.12 для x86_64 с соответствующей версией "perf" на разных системах Intel Core i5 и i7 (тип Ivy Bridge). Ни один из них не поддерживает стоп-цикл-бэкэнд.

Дополнительная информация:

$ perf list | grep stalled
  stalled-cycles-frontend OR idle-cycles-frontend    [Hardware event]
  stalled-cycles-frontend OR cpu/stalled-cycles-frontend/ [Kernel PMU event]

$ ls /sys/devices/cpu/events/
branch-instructions  bus-cycles    cache-references  instructions  mem-stores
branch-misses        cache-misses  cpu-cycles        mem-loads     stalled-cycles-frontend

$ cat /sys/bus/event_source/devices/cpu/events/stalled-cycles-frontend
event=0x0e,umask=0x01,inv,cmask=0x01

Изменить: просто попробовал это на процессоре AMD Phenom II X6 1045T под Ubuntu 12.04 с Linux 3.2 (32bit) - и здесь он показывает значения как для остановленных циклов - frontend и stalled- циклы-бэкенд.

Ответ 1

Похоже, что perf не обновлялся, чтобы понять все события мониторинга производительности, поддерживаемые Ivy Bridge. К счастью, существует общий, хотя и громоздкий интерфейс, который позволяет вам получить доступ к полному списку событий мониторинга производительности. Я не видел stalled-cycles-backend в списке, когда я быстро посмотрел на него, но, возможно, я пропустил его, или, может быть, они сломали его всеми событиями, которые могли бы остановить сервер.

Начнем с

perf list --help

... показывает следующее ПРИМЕЧАНИЕ

    1. Intel(R) 64 and IA-32 Architectures Software Developer Manual
       Volume 3B: System Programming Guide
       http://www.intel.com/Assets/PDF/manual/253669.pdf

... вооруженный этим URL-адресом, вы попадаете в

http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3b-part-2-manual.pdf

... вы хотите раздел 19.3

19.3 МОНИТОРИНГ ПРОИЗВОДИТЕЛЬНОСТИ СОБЫТИЙ ДЛЯ 3-Й ГЕНЕРАЦИИ ПРОЦЕССОРЫ INTEL® CORE ™Процессоры третьего поколения Intel® Core ™ и семейство продуктов Intel Xeon E3-1200 v2 основаны на кодовом имени микросхемы Intel Ivy Bridge. Они поддерживают мероприятия по мониторингу эффективности архитектуры, перечисленные в таблице 19-1. Неархитектурные события мониторинга производительности в ядре процессора перечислены в таблице 19-5. События в таблице 19-5 применяются к процессорам с сигнатурой CPUID кодировки DisplayFamily_DisplayModel со следующими значениями: 06_3AH.

... так что для событий architectural вам нужна таблица 19-1

19.1 СОБЫТИЯ СОХРАНЕНИЯ АРХИТЕКТУРНЫХ ПРОИЗВОДИТЕЛЬНОСТИАрхитектурные события производительности представлены в процессорах Intel Core Solo и Intel Core Duo. Они также поддерживаются процессорами на базе микроархитектуры Intel Core. В таблице 19-1 перечислены заранее определенные события архитектурной производительности, которые могут быть сконфигурированы с использованием счетчиков производительности общего назначения и соответствующих регистров выбора событий.

** Таблица 19-1. События в области архитектуры

... теперь идет сложная часть, вы берете UMask Value как верхние 2 шестнадцатеричные цифры, а Event Num - младшие 2 шестнадцатеричные цифры 4-х разрядного регистра аппаратного номера, которые должны быть присвоены perf stat.

perf stat --help

   -e, --event=
       Select the PMU event. Selection can be a symbolic event name (use
       perf list to list all events) or a raw PMU event (eventsel+umask) in
       the form of rNNN where NNN is a hexadecimal event descriptor.

... он говорит NNN, но вы можете дать ему NNNN. Убедитесь, что это работает, задайте perf stat для пропусков кеша как символьного имени события, так и шестнадцатеричного числа из таблицы 19-1. Мы будем ссылаться на команду date для простоты.

$ perf stat -e r412e -e cache-misses date

Fri Mar 28 09:28:52 CDT 2014

Performance counter stats for 'date':

          2292 r412e                                                       
          2292 cache-misses                                                

   0.003322663 seconds time elapsed

$

Как вы можете видеть, оба сообщили тот же номер, насколько это хорошо. Теперь переходим к таблице 19-5 для не архитектурных аппаратных регистров, из которых слишком много слишком списка, но я перечислю несколько:

Ответ 2

perf (или его часть в ядре) не обновлялась для поддержки вашего процессора, поэтому перфомант не может сопоставить имя генерируемого события "stalled-cycles-backend" с фактическим событием HW.

В таком случае легче найти имена событий; например для процессоров Intel - от руководства по оптимизации Intel http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf (который группирует события по типу и объясняет, как использовать их для измерения различных частей). Не иметь аналогичного документа для AMD.

Чтобы использовать имена событий с perf без ручного преобразования в исходные идентификаторы событий (например, amdn говорит в своем ответе), вы можете использовать сценарии конвертера showevtinfo и check_events from perfmon2 (libpfm4; папка примеров), как описано в статье "Как контролировать весь диапазон событий производительности ЦП" на Bojan Nikolic http://www.bnikolic.co.uk/blog/hpc-prof-events.html. perfmon2 знает процессоры AMD и Intel и написан на C/С++

Для процессоров Intel самым простым способом является использование ocperf обертки поверх perf из проекта python с открытым исходным кодом от Intel от Andi Kleen "pmu-tools", размещенного в github https://github.com/andikleen/pmu-tools и представлен здесь в ML: https://lwn.net/Articles/556983/ и в блоге Andi http://halobates.de/blog/p/245

ocperf понимает все имена событий Intel из руководства по оптимизации Intel.

ocperf также будет поддерживать каждое событие HW с более старыми ядрами linux. Он имеет собственную базу данных в формате tsv или json со всеми событиями HW и их кодами https://download.01.org/perfmon/ (есть автозагрузчик в pmu- инструменты), и база данных постоянно обновляется работодателями Intel. Формат базы данных документируется в readme: https://download.01.org/perfmon/readme.txt

Для Sandy Bridge/Ivy Bridge или Haswell и ядер 3.10 или новее вы также можете использовать toplev.py script из "pmu-tools" для исследования производительности. Вот описание от его автора, Andi Kleen, http://halobates.de/blog/p/262 "pmu-tools, часть II: toplev" на основе метода TopDown из Ahmad Yasin Как настраивать приложения, используя верхнюю характеристику микроархитектурных проблем и " Анализ сверху вниз. Никогда не проигрывал счетчики производительности "

Ответ 3

Только что нашел Re: perf, x86: добавьте части оставшейся функции хэширования PMU:

> AFAICS backend stall cycles are documented to work on Ivy Bridge.

I'm not aware of any documentation that presents these events
as accurate frontend/backend stalls without using the full
TopDown methology (Optimization manual B.3.2)

Таким образом, счетчики вторжений с тактовой частотой IIUC слишком ненадежны на Ivy Bridge, и поэтому разработчики ядра решили не поддерживать их.

И, конечно же, Linux perf_event_intel.c поддерживает PERF_COUNT_HW_STALLED_CYCLES_BACKEND для Nehalem, Xeon E7 и SandyBridge, но не для IvyBridge. PERF_COUNT_HW_STALLED_CYCLES_FRONTEND поддерживается для IvyBridge.

Итак, я думаю, что не будет способа получить этот счетчик на моем текущем процессоре - либо переключить процессоры, либо использовать полную методологию сверху вниз, упомянутую в почте (и описано здесь и здесь)