이러한 이벤트의 작성자에 따르면 이러한 이벤트는 느슨하게 정의되었으며 사용 가능한 CPU 성능 카운터로 추정됩니다. 아시다시피 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)
Andi Kleen의 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:
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)
성능 이벤트 : 일반 프런트 엔드 및 백엔드 지연주기 이벤트 정의 추가 두 가지 일반 하드웨어 이벤트 (프런트 엔드 및 백엔드 지연주기)를 추가합니다.
이러한 이벤트는 CPU가 코드를 실행하지만 해당 기능이 완전히 활용되지 않을 때 조건을 측정합니다. 이러한 상황을 이해하고 분석하는 것은 코드 최적화 워크 플로의 중요한 하위 작업입니다.
두 이벤트 모두 성능을 제한합니다. 대부분의 프런트 엔드 중단은 분기 오 예측 또는 명령 가져 오기 캐시 누락으로 인해 발생하는 경향이 있으며, 백엔드 중단은 다양한 리소스 부족 또는 비효율적 인 명령 스케줄링으로 인해 발생할 수 있습니다.
프런트 엔드 스톨이 더 중요한 요소입니다. 명령어 스트림이 유지되지 않으면 코드가 빠르게 실행될 수 없습니다.
백엔드를 과도하게 사용하면 프론트 엔드 중단이 발생할 수 있으므로주의를 기울여야합니다.
정확한 구성은 프로그램 로직과 명령어 믹스에 따라 다릅니다.
우리는 'stall', 'front-end'및 'back-end'라는 용어를 느슨하게 사용하고 이러한 개념에 근접한 특정 CPU에서 사용 가능한 최상의 이벤트를 사용하려고합니다.
참조 : Peter Zijlstra 참조 : Arnaldo Carvalho de Melo 참조 : Frederic Weisbecker 링크 : http://lkml.kernel.org/n/tip-7y40wib8n000io7hjpn1dsrm@git.kernel.org
서명자 : 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,