'perf stat'결과에서 stalled-cycles-frontend 및 stalled-cycles-backend는 무엇입니까?
누구든지 perf stat 결과에서 stalled-cycles-frontend 및 stalled-cycles-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
이론 :
이제부터 시작해 보겠습니다. 오늘날의 CPU는 수퍼 스칼라이므로주기 당 하나 이상의 명령 (IPC)을 실행할 수 있습니다. 최신 Intel 아키텍처는 최대 4 개의 IPC (4 개의 x86 명령어 디코더)까지 확장 할 수 있습니다. 더 복잡하게하기 위해 매크로 / 마이크로 융합을 논의하지 마십시오. :).
일반적으로 워크로드는 다양한 리소스 경합으로 인해 IPC = 4에 도달하지 않습니다. 이는 CPU가주기를 낭비하고 있음을 의미합니다 (명령의 수는 소프트웨어에 의해 제공되며 CPU는 가능한 한 적은 주기로 실행해야합니다).
CPU가 소비하는 총주기를 세 가지 범주로 나눌 수 있습니다.
- 지침이 폐기되는주기 (유용한 작업)
- 백엔드에서 소비되는주기 (낭비 됨)
- 프런트 엔드에서 소비 된 사이클 (낭비 됨).
IPC 4를 얻으려면 폐기 되는 주기 수가 총 주기 수에 가까워 야합니다. 이 단계에서는 모든 마이크로 작업 (uOps)이 파이프 라인에서 폐기되고 그 결과를 레지스터 / 캐시에 커밋한다는 점에 유의하십시오. 이 단계에서는 4 개 이상의 uOps가 폐기 될 수 있습니다.이 숫자는 실행 포트 수로 제공되기 때문입니다. 4 uOps를 폐기하는주기의 25 % 만있는 경우 전체 IPC는 1입니다.
백 엔드에서 교착 상태주기 (- SQRT, 역수, 부서 등 예를 들어 transcedentals) CPU가 자원 (보통 메모리)를 기다려야 또는 긴 대기 시간 지침을 완료하기 때문에 낭비입니다.
프런트 엔드에서 교착 상태주기는 낭비 프런트 엔드 마이크로 작업으로 백 엔드를 공급하지 않는 것을 의미하기 때문이다. 이는 명령 캐시에 누락이 있거나 마이크로 작업 캐시에서 아직 디코딩되지 않은 복잡한 명령이 있음을 의미 할 수 있습니다. Just-in-time 컴파일 된 코드는 일반적으로이 동작을 표현합니다.
또 다른 지연 이유는 분기 예측 미스입니다. 이를 나쁜 추측이라고합니다. 이 경우 uOps가 발행되지만 BP가 잘못 예측했기 때문에 폐기됩니다.
프로파일 러의 구현 :
BE 및 FE 정지 사이클을 어떻게 해석합니까?
프로파일 러마다 이러한 메트릭에 대한 접근 방식이 다릅니다. vTune에서 카테고리 1 ~ 3이 더해져주기의 100 %를 제공합니다. CPU가 멈췄거나 (uOps가 폐기되지 않음) 유용한 작업 (uOps) 폐기를 수행하기 때문에 그 솔기가 합리적입니다. 자세한 내용은 https://software.intel.com/sites/products/documentation/doclib/stdxe/2013SP1/amplifierxe/snb/index.htm을 참조하십시오.
perf에서는 일반적으로 발생하지 않습니다. 125 % 사이클이 프런트 엔드에서 멈춘 것을 볼 때 실제로이를 해석하는 방법을 알지 못 하기 때문에 문제가됩니다 . 4 개의 디코더가 있다는 사실과> 1 메트릭을 연결할 수 있지만 추론을 계속하면 IPC가 일치하지 않습니다.
더 좋은 점은 문제가 얼마나 큰지 모릅니다. 무엇에서 125 %? 그러면 #cycles는 무엇을 의미합니까?
나는 개인적으로 perf의 BE 및 FE 지연된 사이클에 대해 약간 의심스러워 보이며 이것이 해결되기를 바랍니다.
아마도 우리는 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/perf/builtin-stat.c 에서 코드를 디버깅하여 최종 답을 얻을 것입니다.
perf에서 내 보낸 일반 이벤트를 CPU 문서 원시 이벤트로 변환하려면 다음을 실행할 수 있습니다.
more /sys/bus/event_source/devices/cpu/events/stalled-cycles-frontend
그것은 당신에게 다음과 같은 것을 보여줄 것입니다
event=0x0e,umask=0x01,inv,cmask=0x01
인텔 문서 SDM 볼륨 3B 에 따르면 (코어 i5-2520이 있습니다) :
UOPS_ISSUED.ANY :
- RAT에서 RS로 발행 한 Uop 수를 각주기마다 증가시킵니다.
- 이 코어의 정지 된주기를 계산하려면 Cmask = 1, Inv = 1, Any = 1을 설정합니다.
내 시스템에서 event = 0xb1, umask = 0x01로 변환되는 stalled-cycles-backend 이벤트의 경우 동일한 문서에 다음과 같이 표시됩니다.
UOPS_DISPATCHED.THREAD :
- Counts total number of uops to be dispatched per- thread each cycle
- Set Cmask = 1, INV =1 to count stall cycles.
Usually, stalled cycles are cycles where the processor is waiting for something (memory to be feed after executing a load operation for example) and doesn't have any other stuff to do. Moreover, the frontend part of the CPU is the piece of hardware responsible to fetch and decode instructions (convert them to UOPs) where as the backend part is responsible to effectively execute the UOPs.
A CPU cycle is “stalled” when the pipeline doesn't advance during it.
Processor pipeline is composed of many stages: the front-end is a group of these stages which is responsible for the fetch and decode phases, while the back-end executes the instructions. There is a buffer between front-end and back-end, so when the former is stalled the latter can still have some work to do.
Taken from http://paolobernardi.wordpress.com/2012/08/07/playing-around-with-perf/
According to author of these events, they defined loosely and are approximated by available CPU performance counters. As I know, perf doesn't support formulas to calculate some synthetic event based on several hardware events, so it can't use front-end/back-end stall bound method from Intel's Optimization manual (Implemented in VTune) http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf "B.3.2 Hierarchical Top-Down Performance Characterization Methodology"
%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)
Right formulas can be used with some external scripting, like it was done in Andi Kleen's pmu-tools (toplev.py): https://github.com/andikleen/pmu-tools (source), http://halobates.de/blog/p/262 (description):
% 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.
Commit which introduced stalled-cycles-frontend and stalled-cycles-backend events instead of original universal stalled-cycles:
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 events: Add generic front-end and back-end stalled cycle event definitions Add two generic hardware events: front-end and back-end stalled cycles.
These events measure conditions when the CPU is executing code but its capabilities are not fully utilized. Understanding such situations and analyzing them is an important sub-task of code optimization workflows.
Both events limit performance: most front end stalls tend to be caused by branch misprediction or instruction fetch cachemisses, backend stalls can be caused by various resource shortages or inefficient instruction scheduling.
Front-end stalls are the more important ones: code cannot run fast if the instruction stream is not being kept up.
An over-utilized back-end can cause front-end stalls and thus has to be kept an eye on as well.
The exact composition is very program logic and instruction mix dependent.
We use the terms 'stall', 'front-end' and 'back-end' loosely and try to use the best available events from specific CPUs that approximate these concepts.
Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Frederic Weisbecker Link: http://lkml.kernel.org/n/tip-7y40wib8n000io7hjpn1dsrm@git.kernel.org Signed-off-by: Ingo Molnar
/* 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,
'Program Tip' 카테고리의 다른 글
| MySQL Workbench 다크 테마 (0) | 2020.11.11 |
|---|---|
| JSP 용 클래스를 컴파일 할 수 없음 : java.util.Map $ Entry 유형을 분석 할 수 없습니다. (0) | 2020.11.11 |
| forEach 대 forEachOrdered in Java 8 Stream (0) | 2020.11.11 |
| Docker 컨테이너 내부에 심볼릭 링크가있는 호스트 디렉터리 마운트 (0) | 2020.11.11 |
| 문자의 유니 코드 값 가져 오기 (0) | 2020.11.11 |