Що таке затримка циклів-інтерфейсу та затримка циклів-бекенда в результаті 'perf stat'?

Question 1

Хто-небудь знає, що означає staled-cycles-frontend та stalled-cycles-backend у результатах per stat? Я шукав в Інтернеті, але не знайшов відповіді. Дякую

$ 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

Question 2

Теорія:

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

Як правило, робоче навантаження не досягає IPC = 4 через різні обмеження ресурсів. Це означає, що центральний процесор витрачає цикли (кількість інструкцій дається програмним забезпеченням, і центральний процесор повинен виконувати їх за якомога менше циклів).

Ми можемо розділити загальний цикл, витрачений процесором, на 3 категорії:

Цикли, коли інструкції припиняють роботу (корисна робота)
Цикли, що проводяться в Back-End (марно)
Цикли, проведені в Front-End (даремно).

Щоб отримати IPC 4, кількість циклів, що виходять із системи, повинна бути близькою до загальної кількості циклів. Майте на увазі, що на цьому етапі всі мікрооперації (uOps) виходять із конвеєру та фіксують свої результати в регістрах / кешах. На цьому етапі у вас може вийти навіть більше 4 uOps, оскільки це число визначається кількістю портів виконання. Якщо у вас є лише 25% циклів, які припиняють 4 uOps, тоді у вас буде загальний IPC 1.

У циклах Тупик в фоновому є відходами , тому що процесор повинен чекати ресурсів ( як правило , пам'ять) або закінчити довгі затримки команд (наприклад , transcedentals - SQRT, зворотні, підрозділ і т.д.).

У циклах Тупик в передньому кінці є відходами , оскільки це означає , що Front-End не мав Back End з мікрооперацій. Це може означати, що у вас є пропуски в кеші інструкцій або складні інструкції, які ще не розшифровані в кеші мікро-операції. Складений своєчасно код зазвичай виражає таку поведінку.

Ще однією причиною стійла є прогнозування гілок. Це називається поганою спекуляцією. У цьому випадку видаються 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% з чого? Що тоді означають #cycles?

Я особисто виглядаю трохи підозріло щодо зупинених циклів BE та FE, і сподіваюся, це буде виправлено.

Можливо, остаточну відповідь ми отримаємо шляхом налагодження коду звідси: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/perf/builtin-stat.c

Question 3

Щоб перетворити загальні події, експортовані 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-cycles-backend, що перекладається на event = 0xb1, umask = 0x01 у моїй системі, та сама документація говорить:

UOPS_DISPATCHED.THREAD:

Підраховує загальну кількість передач, які потрібно відправити за потік кожного циклу
Встановіть Cmask = 1, INV = 1 для підрахунку циклів зупинки.

Зазвичай зупинені цикли - це цикли, коли процесор чекає чогось (наприклад, пам'ять буде подано після виконання операції завантаження) і не має жодних інших речей. Більше того, фронтальна частина центрального процесора - це апаратне забезпечення, відповідальне за отримання та декодування інструкцій (перетворення їх в UOP), де як внутрішня частина відповідає за ефективне виконання UOP.

Question 4

Цикл процесора «затримується», коли трубопровід не просувається під час нього.

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

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

Question 5

За словами автора цих подій, вони визначені вільно і апроксимуються доступними лічильниками продуктивності процесора. Як я знаю, 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 Andi Kleen ( toplev.py): https://github.com/andikleen/pmu-tools (джерело), http://halobates.de/blog/ р / 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-frontend та stalled-cycles-backend замість оригінальних універсальних stalled-cycles:

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

author  Ingo Molnar <mingo@el...>   2011-04-29 11:19:47 (GMT)
committer   Ingo Molnar <mingo@el...>   2011-04-29 12:23:58 (GMT)
commit  8f62242246351b5a4bc0c1f00c0c7003edea128a (patch)
tree    9021c99956e0f9dc64655aaa4309c0f0fdb055c9
parent  ede70290046043b2638204cab55e26ea1d0c6cd9 (diff)

події perf: Додайте загальні визначення подій застосованого циклу інтерфейсу та back-end Додайте дві загальні події обладнання: front-end та back-end зупинені цикли.

Ці події вимірюють умови, коли центральний процесор виконує код, але його можливості використовуються не повністю. Розуміння таких ситуацій та їх аналіз є важливою підзавданням процесів оптимізації коду.

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

Фронтальні кіоски є найбільш важливими: код не може швидко працювати, якщо потік інструкцій не підтримується.

Надмірно використаний інтерфейс може спричинити фронтові кіоски, і, отже, за ним слід також стежити.

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

Ми вільно використовуємо терміни "стійло", "інтерфейс" і "фоновий сервер" і намагаємось використовувати найкращі доступні події з конкретних процесорів, які відповідають цим поняттям.

Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Frederic Weisbecker Посилання: http://lkml.kernel.org/n/tip-7y40wib8n000io7hjpn1dsrm@git.kernel.org Підписав: Інго Молнар

    /* 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,