it-roy-ru.com

Каковы результаты stalled-cycles-frontend и stalled-cycles-backend в результате 'perf stat'?

Кто-нибудь знает, что означает stalled-cycles-frontend и stalled -cles-backend в результате выполнения статистики? Я искал в интернете, но не нашел ответа. Спасибо

$ Sudo perf stat ls                     

Performance counter stats for 'ls':

      0.602144 task-clock                #    0.762 CPUs utilized          
             0 context-switches          #    0.000 K/sec                  
             0 CPU-migrations            #    0.000 K/sec                  
           236 page-faults               #    0.392 M/sec                  
        768956 cycles                    #    1.277 GHz                    
        962999 stalled-cycles-frontend   #  125.23% frontend cycles idle   
        634360 stalled-cycles-backend    #   82.50% backend  cycles idle
        890060 instructions              #    1.16  insns per cycle        
                                         #    1.08  stalled cycles per insn
        179378 branches                  #  297.899 M/sec                  
          9362 branch-misses             #    5.22% of all branches         [48.33%]

   0.000790562 seconds time elapsed
64
Dafan

Теория:

Давайте начнем с этого: в настоящее время ЦП являются суперскалярными, что означает, что они могут выполнять более одной инструкции за цикл (IPC). Последние архитектуры Intel могут иметь до 4 IPC (4 декодера команд x86). Давайте не будем обсуждать макро/микро слияние, чтобы усложнить ситуацию :).

Как правило, рабочие нагрузки не достигают IPC = 4 из-за разногласий в ресурсах. Это означает, что ЦП теряет циклы (количество инструкций задается программным обеспечением, и ЦП должен выполнять их за как можно меньшее количество циклов).

Мы можем разделить общее количество циклов, затраченных процессором, на 3 категории:

  1. Циклы, где инструкции удаляются (полезная работа)
  2. Циклы, проводимые в Back-End (впустую)
  3. Циклы, проведенные в Front-End (впустую).

Чтобы получить IPC из 4, количество повторяющихся циклов должно быть близко к общему количеству циклов. Помните, что на этом этапе все микрооперации (uOps) удаляются из конвейера и фиксируют свои результаты в регистрах/кэшах. На этом этапе вы можете удалить даже более 4 мегапикселей, потому что это число определяется числом портов выполнения. Если у вас есть только 25% циклов, выходящих на пенсию по 4 uOps, тогда у вас будет общее IPC 1.

Циклы , остановленные во внутреннем интерфейсе , являются пустой тратой, поскольку ЦП должен ждать ресурсы (обычно память) или завершать выполнение инструкций с большой задержкой (например, transcedentals). - sqrt, взаимные ссылки, деления и т. д.).

Циклы , остановленные во внешнем интерфейсе , являются пустой тратой, потому что это означает, что внешний интерфейс не питает внутренний конец микрооперациями. Это может означать, что в кеше инструкций есть ошибки или сложные инструкции, которые еще не декодированы в кеше микроопераций. Скомпилированный код точно в срок обычно выражает это поведение.

Еще одна причина задержки - промах прогнозирования ветвей. Это называется плохой спекуляцией. В этом случае uOps выдаются, но они отбрасываются, потому что BP предсказал неверно.

Реализация в профилировщиках:

Как вы интерпретируете застойные циклы BE и FE?

Различные профилировщики имеют разные подходы к этим метрикам. В vTune категории с 1 по 3 складываются, давая 100% циклов. Это кажется разумным, потому что либо ваш процессор остановлен (ни один uOps не удаляется), либо он выполняет полезную работу (uOps), удаляясь. Подробнее здесь: https://software.intel.com/sites/products/documentation/doclib/stdxe/2013SP1/amplifierxe/snb/index.htm

В перфе такого обычно не бывает. Это проблема, потому что, когда вы видите 125% циклов, остановленных во внешнем интерфейсе , вы не знаете, как на самом деле это интерпретировать. Вы можете связать метрику> 1 с тем фактом, что имеется 4 декодера, но если вы продолжите рассуждение, то IPC не будет совпадать.

Даже лучше, вы не знаете, насколько велика проблема. 125% из чего? Что же тогда означают циклы?

Я лично выгляжу немного подозрительно по поводу циклов BE и FE в тупике и надеюсь, что это будет исправлено.

Вероятно, мы получим окончательный ответ, отладив код здесь: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/perf/builtin- stat.c

46
VAndrei

Чтобы преобразовать обобщенные события, экспортируемые через perf, в необработанные события документации вашего процессора, вы можете запустить:

more /sys/bus/event_source/devices/cpu/events/stalled-cycles-frontend 

Это покажет вам что-то вроде

event=0x0e,umask=0x01,inv,cmask=0x01

Согласно документация Intel SDM, том 3B (у меня ядро ​​i5-2520):

UOPS_ISSUED.ANY:

  • Увеличивает каждый цикл # Uops, выданных RAT для RS.
  • Установите Cmask = 1, Inv = 1, Any = 1 для подсчета остановленных циклов этого ядра.

Для события stalled-cycle-backend, преобразующегося в event = 0xb1, umask = 0x01 в моей системе, в той же документации сказано:

UOPS_DISPATCHED.THREAD:

  • Подсчитывает общее количество мопов, которые должны быть отправлены за каждый цикл
  • Установите Cmask = 1, INV = 1 для подсчета циклов остановки.

Обычно остановленные циклы - это циклы, в которых процессор ожидает чего-либо (например, память, которая будет загружена после выполнения операции загрузки) и не имеет никаких других действий. Более того, внешняя часть ЦП является частью аппаратного обеспечения, ответственной за выборку и декодирование инструкций (преобразование их в UOP), где в качестве серверной части отвечает за эффективное выполнение UOP.

38
Manuel Selva

Цикл ЦП "останавливается", когда конвейер не продвигается во время него.

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

Взято из http://paolobernardi.wordpress.com/2012/08/07/playing-around-with-perf/

12
Milind Dumbare

По словам автора этих событий, они определены слабо и аппроксимируются доступными счетчиками производительности процессора. Как я знаю, perf не поддерживает формулы для вычисления какого-то синтетического события на основе нескольких аппаратных событий, поэтому он не может использовать метод привязки внешнего/внутреннего конца из руководства по оптимизации Intel (реализовано в VTune) http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf "B.3.2 Иерархический нисходящий Методология определения характеристик "

%FE_Bound = 100 * (IDQ_UOPS_NOT_DELIVERED.CORE / N ); 
%Bad_Speculation = 100 * ( (UOPS_ISSUED.ANY – UOPS_RETIRED.RETIRE_SLOTS + 4 * INT_MISC.RECOVERY_CYCLES ) / N) ; 
%Retiring = 100 * ( UOPS_RETIRED.RETIRE_SLOTS/ N) ; 
%BE_Bound = 100 * (1 – (FE_Bound + Retiring + Bad_Speculation) ) ; 
N = 4*CPU_CLK_UNHALTED.THREAD" (for SandyBridge)

Правильные формулы можно использовать с некоторыми внешними сценариями, как это было сделано в pmu-tools Энди Клина (toplev.py): https://github.com/andikleen/pmu-tools (источник), - http://halobates.de/blog/p/262 (описание):

% toplev.py -d -l2 numademo  100M stream
...
perf stat --log-fd 4 -x, -e
{r3079,r19c,r10401c3,r100030d,rc5,r10e,cycles,r400019c,r2c2,instructions}
{r15e,r60006a3,r30001b1,r40004a3,r8a2,r10001b1,cycles}
numademo 100M stream
...
BE      Backend Bound:                      72.03%
    This category reflects slots where no uops are being delivered due to a lack
    of required resources for accepting more uops in the    Backend of the pipeline.
 .....
FE      Frontend Bound:                     54.07%
This category reflects slots where the Frontend of the processor undersupplies
its Backend.

Фиксация, в которой вместо исходных универсальных stalled-cycles были введены события stalled-cycle-frontend и stalled-cycle-backend:

http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=8f62242246351b5a4bc0c1f00c0c7003edea128a

author  Ingo Molnar <[email protected]>   2011-04-29 11:19:47 (GMT)
committer   Ingo Molnar <[email protected]>   2011-04-29 12:23:58 (GMT)
commit  8f62242246351b5a4bc0c1f00c0c7003edea128a (patch)
tree    9021c99956e0f9dc64655aaa4309c0f0fdb055c9
parent  ede70290046043b2638204cab55e26ea1d0c6cd9 (diff)

события perf: добавление общих определений событий остановленных циклов внешнего и внутреннего интерфейсов. Добавьте два общих аппаратных события: циклы остановленных входных и внутренних процессов.

Эти события измеряют условия, когда процессор выполняет код, но его возможности используются не полностью. Понимание таких ситуаций и их анализ является важной подзадачей рабочих процессов оптимизации кода.

Оба события ограничивают производительность: большинство остановок внешнего интерфейса, как правило, вызваны ошибочным прогнозированием ветвлений или кэшированием выборки команд, задержки внутреннего интерфейса могут быть вызваны различными нехватками ресурсов или неэффективным планированием команд.

Фронтальные киоски являются более важными: код не может работать быстро, если поток команд не поддерживается.

Чрезмерно используемая задняя часть может привести к остановкам переднего конца и, следовательно, также должна следить за ней.

Точная композиция очень зависит от программной логики и набора команд.

Мы свободно используем термины "stall", "front-end" и "back-end" и пытаемся использовать лучшие доступные события от конкретных процессоров, которые приближают эти понятия.

Копия: Питер Зийльстра Копия: Арнальдо Карвалью де Мело Копия: Фредерик Вайсбекер Ссылка: http://lkml.kernel.org/n/[email protected] Подписано: Инго Молнар

    /* Install the stalled-cycles event: UOPS_EXECUTED.CORE_ACTIVE_CYCLES,c=1,i=1 */
-       intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES] = 0x1803fb1;
+       intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = 0x1803fb1;

-   PERF_COUNT_HW_STALLED_CYCLES        = 7,
+   PERF_COUNT_HW_STALLED_CYCLES_FRONTEND   = 7,
+   PERF_COUNT_HW_STALLED_CYCLES_BACKEND    = 8,
11
osgx