perf_events 목록에있는 커널 PMU 이벤트는 무엇입니까?


11

Linux에서 모니터링 할 수 있는 항목을 검색 할 때 무엇을perf_events 찾을 수 Kernel PMU event없습니까? 즉, 다음과 perf version 3.13.11-ckt39같은 perf list쇼 이벤트가 있습니다.

branch-instructions OR cpu/branch-instructions/    [Kernel PMU event]

전반적으로 다음이 있습니다.

Tracepoint event
Software event
Hardware event
Hardware cache event
Raw hardware event descriptor
Hardware breakpoint
Kernel PMU event

나는 그들이 어디에서 왔는지 이해하고 싶습니다. 나는 모든 종류의 물건에 대한 설명이 Kernel PMU event있습니다.

에서 반환 한 위키 튜토리얼브렌든 그레그의 페이지 나는 그것을 얻을 :

  • Tracepoints가장 명확합니다. 커널 소스의 매크로입니다. 모니터링을위한 조사 지점을 만들고 ftrace프로젝트와 함께 소개 되었으며 이제 모든 사람이 사용합니다.
  • Software 커널의 저수준 카운터 및 일부 내부 데이터 구조 (따라서 추적 점과는 다름)
  • Hardware event모든 아키텍처 에서 발견 되고 커널이 쉽게 액세스 할 수 있는 매우 기본적인 CPU 이벤트입니다.
  • Hardware cache event별명입니다 Raw hardware event descriptor-다음과 같이 작동합니다

    내가 알았을 Raw hardware event descriptor때보 다 (마이크로?) 아키텍처 관련 이벤트가 이벤트보다 많으며 Hardware event, PMU (Processor Monitoring Unit) 또는 특정 프로세서의 기타 특정 기능에서 발생하는 이벤트이므로 일부 마이크로 아키텍처에서만 사용할 수 있습니다 ( ' 아키텍처 "는"x86_64 "를 의미하고 나머지 모든 구현 세부 사항은"마이크로 아키텍처 "입니다. 이 이상한 설명자를 통해 계측에 액세스 할 수 있습니다.

    rNNN                                               [Raw hardware event descriptor]
    cpu/t1=v1[,t2=v2,t3 ...]/modifier                  [Raw hardware event descriptor]
     (see 'man perf-list' on how to encode it)
    

    -이 디스크립터, 이들이 가리키는 이벤트 등은 프로세서 매뉴얼 ( perf wiki의 PMU 이벤트)에서 찾을 수 있습니다 .

    그러나 사람들이 주어진 프로세서에 유용한 이벤트가 있다는 것을 알면 별명을 부여하고 Hardware cache event쉽게 액세스 할 수 있도록 리눅스 에 연결합니다.

    - 내가 틀렸다면 정확한 날 (모든 이상하게 Hardware cache event에 대한 있습니다 something-loads또는 something-misses- 매우 실제 프로세서의 캐시처럼 ..)

  • 이제 Hardware breakpoint

    mem:<addr>[:access]                                [Hardware breakpoint]
    

    하드웨어 기능이며, 대부분의 최신 아키텍처에 공통적이며 디버거에서 중단 점으로 작동합니까? (아마도 그것은 어설프다)

  • 마지막으로, Kernel PMU event나는 구글을 관리하지 못한다.

    또한 Brendan의 perf page에있는 이벤트 목록 에도 표시되지 않으므로 새로운 기능입니까?

    어쩌면 PMU에서 하드웨어 이벤트의 별명일까요? (접근 용이성을 위해 별명 외에도 이벤트 목록에 별도의 섹션이 있습니다.) 실제로 Hardware cache eventsCPU 캐시의 하드웨어 이벤트에 대한 별명 일 수도 있고 Kernel PMU eventPMU 이벤트에 대한 별명일까요? (그런데 왜 그렇게 부르지 Hardware PMU event않습니까?.) 새로운 이름 지정 체계 일 수 있습니다. 하드웨어 이벤트의 별명은 섹션화 되었습니까?

    그리고 이러한 이벤트는 cpu/mem-stores/일부 Linux 버전 이벤트에 설명이 있으므로 다음 과 같은 것을 참조하십시오 /sys/devices/.

    # find /sys/ -type d -name events
    /sys/devices/cpu/events
    /sys/devices/uncore_cbox_0/events
    /sys/devices/uncore_cbox_1/events
    /sys/kernel/debug/tracing/events
    

    - debug/tracing입니다 ftrace및 추적 점은, 다른 디렉토리는 정확하게 일치 perf list로 보여줍니다 Kernel PMU event.

누군가 나에게 Kernel PMU events또는 /sys/..events/시스템이 무엇인지에 대한 좋은 설명 / 문서를 알려 줄 수 있습니까? 또한 /sys/..events/하드웨어 이벤트 등을 체계화하려는 새로운 노력이 있습니까? (커널 PMU는 "커널의 성능 모니터링 장치"와 같습니다.)

추신

더 나은 컨텍스트를 제공하기 위해 s 및 s 의 perf list전체 목록을 포함하여 권한이없는 실행 (추적 점은 표시되지 않지만 1374가 모두 있습니다)이 생략되었습니다.Kernel PMU eventHardware cache event

$ perf list 

List of pre-defined events (to be used in -e):
 cpu-cycles OR cycles                               [Hardware event]
 instructions                                       [Hardware event]
 ...
 cpu-clock                                          [Software event]
 task-clock                                         [Software event]
 ...
 L1-dcache-load-misses                              [Hardware cache event]
 L1-dcache-store-misses                             [Hardware cache event]
 L1-dcache-prefetch-misses                          [Hardware cache event]
 L1-icache-load-misses                              [Hardware cache event]
 LLC-loads                                          [Hardware cache event]
 LLC-stores                                         [Hardware cache event]
 LLC-prefetches                                     [Hardware cache event]
 dTLB-load-misses                                   [Hardware cache event]
 dTLB-store-misses                                  [Hardware cache event]
 iTLB-loads                                         [Hardware cache event]
 iTLB-load-misses                                   [Hardware cache event]
 branch-loads                                       [Hardware cache event]
 branch-load-misses                                 [Hardware cache event]

 branch-instructions OR cpu/branch-instructions/    [Kernel PMU event]
 branch-misses OR cpu/branch-misses/                [Kernel PMU event]
 bus-cycles OR cpu/bus-cycles/                      [Kernel PMU event]
 cache-misses OR cpu/cache-misses/                  [Kernel PMU event]
 cache-references OR cpu/cache-references/          [Kernel PMU event]
 cpu-cycles OR cpu/cpu-cycles/                      [Kernel PMU event]
 instructions OR cpu/instructions/                  [Kernel PMU event]
 mem-loads OR cpu/mem-loads/                        [Kernel PMU event]
 mem-stores OR cpu/mem-stores/                      [Kernel PMU event]
 ref-cycles OR cpu/ref-cycles/                      [Kernel PMU event]
 stalled-cycles-frontend OR cpu/stalled-cycles-frontend/ [Kernel PMU event]
 uncore_cbox_0/clockticks/                          [Kernel PMU event]
 uncore_cbox_1/clockticks/                          [Kernel PMU event]

 rNNN                                               [Raw hardware event descriptor]
 cpu/t1=v1[,t2=v2,t3 ...]/modifier                  [Raw hardware event descriptor]
  (see 'man perf-list' on how to encode it)

 mem:<addr>[:access]                                [Hardware breakpoint]

 [ Tracepoints not available: Permission denied ]

답변:


11

인터넷 검색 및 ack노래가 끝났습니다! 답변이 있습니다.

그러나 먼저 질문의 목표를 좀 더 명확하게 설명하겠습니다. 시스템의 독립적 인 프로세스와 성능 카운터를 명확하게 구별하고 싶습니다. 예를 들어, 프로세서의 코어, 언 코어 장치 (최근에 배운 내용), 프로세서의 커널 또는 사용자 응용 프로그램, 버스 (= 버스 컨트롤러), 하드 드라이브는 모두 독립적 인 프로세스이며 시계에 의해 동기화되지 않습니다 . 그리고 요즘에는 아마도 모두 PMC (Process Monitoring Counter)를 가지고있을 것입니다. 카운터가 어떤 프로세스에서 나오는지 알고 싶습니다. (또한 인터넷 검색에도 도움이됩니다. 사물의 "공급 업체"가 더 좋습니다.

또한 검색에 사용되는 기어 : Ubuntu 14.04,, linux 3.13.0-103-generic프로세서 Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz(에서 /proc/cpuinfo2 개의 물리적 코어와 4 개의 가상 (물리적 물질)를 가짐).

용어, 질문과 관련된 것들

인텔에서 :

  • 프로세서는 하나 core의 장치 / 프로세스이며 하나의 uncore장치 이며 core프로그램을 실행하는 것 (시계, ALU, 레지스터 등)이며, uncore장치가 다이에 장착되어 속도와 낮은 지연 시간을 위해 프로세서에 가깝습니다 (실제 이유) "제조업체가 할 수 있기 때문에"); 내가 이해했듯이 기본적으로 PC 마더 보드와 캐시와 같은 노스 브릿지입니다. AMD는 실제로 이러한 장치를 instead of노스 브릿지 언 코어라고 부릅니다.

  • ubox 내 안에 나타나는 sysfs

    $ find /sys/devices/ -type d -name events 
    /sys/devices/cpu/events
    /sys/devices/uncore_cbox_0/events
    /sys/devices/uncore_cbox_1/events
    

    uncore-Last Level Cache (LLC, RAM에 도달하기 전 마지막 것)를 관리 하는 장치입니다. 나는 2 개의 코어, 따라서 2 개의 LLC와 2를 가지고있다 ubox.

  • PMU (Processor Monitoring Unit)는 프로세서의 작동을 모니터링하고이를 PMC (Processor Monitoring Counter)에 기록하는 별도의 장치입니다 (캐시 누락, 프로세서주기 등). 그들은 존재 core하고 uncore장치; core사람이 사용하여 액세스 rdpmc(읽기 PMC) 명령; uncore이러한 장치가 손에 실제 프로세서에 의존하기 때문에, 경유 모델 고유 레지스터 (MSR)를 통해 액세스된다 rdmsr(자연스럽게);

    분명히, 그것들과의 워크 플로우는 레지스터 쌍을 통해 수행됩니다-카운터가 카운트하는 이벤트 1 레지스터 세트, 2 레지스터는 카운터의 값입니다. 카운터는 1이 아닌 많은 이벤트 후에 증가하도록 구성 될 수 있습니다. +이 카운터에는 몇 가지 interupts / tech noticing overflow가 있습니다.

  • 더 많은 것은 인텔의 "IA-32 소프트웨어 개발자 매뉴얼 Vol 3B"18 장 "성능 모니터링"에서 찾을 수 있습니다.

    또한 uncore"건축 성능 모니터링 버전 1"버전의 PMC에 대한 MSR 형식을 구체적 으로 설명합니다 (매뉴얼에 버전 1-4가 있으며 어떤 프로세서가 내 프로세서인지 모릅니다)는 "그림 18-1. 레이아웃"에 설명되어 있습니다. 표 18-1. 미리 정의 된 건축 성능 이벤트에 대한 UMask 및 이벤트 선택 인코딩 "을 참조하여 IA32_PERFEVTSELx MSR"(18-3 페이지) 및 "18.2.1.2 사전 정의 된 건축 성능 이벤트"섹션 로 표시 이벤트 Hardware event에서 perf list.

리눅스 커널에서 :

  • 커널에는 소프트웨어 (커널)와 하드웨어 모두에서 서로 다른 출처의 성능 카운터를 관리하기위한 시스템 (추상화 / 계층)이 있습니다 linux-source-3.13.0/tools/perf/design.txt. 이 시스템의 이벤트는 struct perf_event_attr(file linux-source-3.13.0/include/uapi/linux/perf_event.h) 로 정의되며 , 주요 부분은 __u64 config필드 일 수 있습니다 .CPU 관련 이벤트 정의 (인텔의 그림에 설명 된 형식의 64 비트 단어) 또는 커널 이벤트를 모두 보유 할 수 있습니다.

    구성 단어의 MSB는 나머지가 [원시 CPU 또는 커널 이벤트]를 포함하는지 여부를 나타냅니다.

    커널 이벤트는 유형에 대해 7 비트와 이벤트 식별자에 대해 56으로 정의되며 enum코드에서 -s이며 내 경우에는 다음과 같습니다.

    $ ak PERF_TYPE linux-source-3.13.0/include/
    ...
    linux-source-3.13.0/include/uapi/linux/perf_event.h
    29: PERF_TYPE_HARDWARE      = 0,
    30: PERF_TYPE_SOFTWARE      = 1,
    31: PERF_TYPE_TRACEPOINT    = 2,
    32: PERF_TYPE_HW_CACHE      = 3,
    33: PERF_TYPE_RAW           = 4,
    34: PERF_TYPE_BREAKPOINT    = 5,
    36: PERF_TYPE_MAX,         /* non-ABI */
    

    ( ak에 대한 나의 별명 ack-grep입니다 ack. 데비안에서 사용 되는 이름입니다 . ack);

    커널의 소스 코드에서 "시스템에서 발견 된 모든 PMU 등록"및 구조 유형 struct pmu과 같은 작업이 다음과 같이 전달 int perf_pmu_register(struct pmu *pmu, const char *name, int type)될 수 있습니다. 따라서이 시스템을 "커널의 PMU"라고 부를 수 있습니다. 시스템의 모든 PMU 중 그러나이 이름은 커널 작동의 모니터링 시스템으로 해석 될 수 있습니다.

    perf_events명확성을 위해이 서브 시스템 을 호출합시다 .

  • 커널 서브 시스템으로이 서브 시스템을 내보낼 수 있습니다 sysfs(사람들이 사용할 수 있도록 커널 서브 시스템을 내보내도록 만들어 짐). 그리고 그것은 events/sys/-내 보낸 (부분) perf_events서브 시스템 의 디렉토리들입니다 .

  • 또한 사용자 공간 유틸리티 perf(Linux에 내장)는 여전히 별도의 프로그램이며 자체 추상화가 있습니다. 이것은 사용자가 perf_evsel(파일 linux-source-3.13.0/tools/perf/util/evsel.{h,c}) 로 모니터링하도록 요청 된 이벤트를 나타냅니다. 이 구조에는 필드 struct perf_event_attr attr;가 있지만 유틸리티가 이벤트를 모든 또는 특정 CPU에 할당하는 struct cpu_map *cpus;방법 과 같은 필드도 있습니다 perf.

대답

  1. 실제로, Hardware cache event캐시 장치 ( ubox인텔 uncore장치) 의 이벤트에 대한 "바로 가기" 는 프로세서별로 다르며 프로토콜을 통해 액세스 할 수 있습니다 Raw hardware event descriptor. 그리고 Hardware event내가 이해하는 것처럼 core장치 내 에서 이벤트 이름을 짓는 아키텍처 내에서 더 안정적 입니다. 커널 3.13에 다른 uncore이벤트 및 카운터에 대한 다른 "단축키"는 없습니다 . 모든 나머지 - SoftwareTracepoints- 커널의 이벤트입니다.

    있는지 궁금해 coreHardware event의이 같은 통해 액세스 Raw hardware event descriptor프로토콜입니다. 카운터 / PMU가 앉기 core때문에 다르게 액세스 할 수 있습니다. 예를 들어, rdpmu대신 해당 명령어 rdmsr로 액세스하는 uncore. 그러나 그렇게 중요하지 않습니다.

  2. Kernel PMU event로 내보내지는 이벤트 일뿐 sysfs입니다. 나는 이것이 어떻게 수행되는지 모른다 (커널에 의해 시스템에서 발견 된 모든 PMC를 자동으로 또는 하드 코딩 된 것, 그리고 내가 추가 kprobe하면 내보내 지는가?) 그러나 요점은 Hardware event내부 perf_event시스템의 이벤트와 동일 하거나 다른 이벤트라는 것 입니다.

    그리고 나는 그 것들을 모른다

    $ ls /sys/devices/uncore_cbox_0/events
    clockticks
    

    아르.

세부 사항 Kernel PMU event

코드를 검색하면 다음이 발생합니다.

$ ak "Kernel PMU" linux-source-3.13.0/tools/perf/
linux-source-3.13.0/tools/perf/util/pmu.c                                                            
629:                printf("  %-50s [Kernel PMU event]\n", aliases[j]);

-기능에서 발생

void print_pmu_events(const char *event_glob, bool name_only) {
   ...
        while ((pmu = perf_pmu__scan(pmu)) != NULL)
                list_for_each_entry(alias, &pmu->aliases, list) {...}
   ... 
   /* b.t.w. list_for_each_entry is an iterator
    * apparently, it takes a block of {code} and runs over some lost
    * Ruby built in kernel!
    */
    // then there is a loop over these aliases and
    loop{ ... printf("  %-50s [Kernel PMU event]\n", aliases[j]); ... }
}

perf_pmu__scan같은 파일에 있습니다 :

struct perf_pmu *perf_pmu__scan(struct perf_pmu *pmu) {
    ...
                pmu_read_sysfs(); // that's what it calls
}

-또한 같은 파일에 있습니다 :

/* Add all pmus in sysfs to pmu list: */
static void pmu_read_sysfs(void) {...}

그게 다야.

에 대한 세부 사항 Hardware eventHardware cache event

분명히,은 Hardware event인텔이 부르는 IA-32 소프트웨어 개발자 설명서 권 3B에서, 18.2.1.2 "건축 성능 이벤트 사전은 정의"에서 왔습니다. 매뉴얼의 "18.1 성능 모니터링 개요"에서는 다음과 같이 설명합니다.

두 번째 등급의 성능 모니터링 기능을 아키텍처 성능 모니터링이라고합니다. 이 클래스는 더 작은 수의 이벤트 세트를 사용하여 동일한 카운팅 및 인터럽트 기반 이벤트 샘플링 사용법을 지원합니다. 아키텍처 성능 이벤트의 가시적 인 동작은 프로세서 구현에서 일관됩니다. 아키텍처 성능 모니터링 기능의 가용성은 CPUID.0AH를 사용하여 열거됩니다. 이러한 이벤트는 18.2 절에서 설명합니다.

다른 유형은 다음과 같습니다.

Intel Core Solo 및 Intel Core Duo 프로세서부터 두 가지 등급의 성능 모니터링 기능이 있습니다. 첫 번째 클래스는 카운팅 또는 인터럽트 기반 이벤트 샘플링 사용량을 사용하여 성능을 모니터링하는 이벤트를 지원합니다. 이러한 이벤트는 비 구조적이며 프로세서 모델마다 다릅니다.

그리고 이러한 이벤트는 실제로 기본 "원시"하드웨어 이벤트에 대한 링크이며 perf유틸리티를 통해 액세스 할 수 있습니다 Raw hardware event descriptor.

이것을 확인하려면 다음을보십시오 linux-source-3.13.0/arch/x86/kernel/cpu/perf_event_intel.c.

/*
 * Intel PerfMon, used on Core and later.
 */
static u64 intel_perfmon_event_map[PERF_COUNT_HW_MAX] __read_mostly =
{
    [PERF_COUNT_HW_CPU_CYCLES]              = 0x003c,
    [PERF_COUNT_HW_INSTRUCTIONS]            = 0x00c0,
    [PERF_COUNT_HW_CACHE_REFERENCES]        = 0x4f2e,
    [PERF_COUNT_HW_CACHE_MISSES]            = 0x412e,
    ...
}

0x412e"LLC Misses"에 대한 "표 18-1. 사전 정의 된 아키텍처 성능 이벤트를위한 UMask 및 이벤트 선택 인코딩"에서 정확히 찾을 수 있습니다.

Bit Position CPUID.AH.EBX | Event Name | UMask | Event Select
...
                        4 | LLC Misses | 41H   | 2EH

- H진수입니다. 7은 모두 구조에 [PERF_COUNT_HW_REF_CPU_CYCLES] = 0x0300, /* pseudo-encoding *있습니다. (이름은 약간 다르고 주소는 동일합니다.)

그런 다음 Hardware cache events는 같은 파일에 다음과 같은 구조로 있습니다.

static __initconst const u64 snb_hw_cache_extra_regs
                            [PERF_COUNT_HW_CACHE_MAX]
                            [PERF_COUNT_HW_CACHE_OP_MAX]
                            [PERF_COUNT_HW_CACHE_RESULT_MAX] =
{...}

-모래 다리는 어느 쪽이어야합니까?

이 중 하나는 위의 def-s에서로 snb_hw_cache_extra_regs[LL][OP_WRITE][RESULT_ACCESS]채워집니다 SNB_DMND_WRITE|SNB_L3_ACCESS.

#define SNB_L3_ACCESS           SNB_RESP_ANY
#define SNB_RESP_ANY            (1ULL << 16)                                                                            
#define SNB_DMND_WRITE          (SNB_DMND_RFO|SNB_LLC_RFO)
#define SNB_DMND_RFO            (1ULL << 1)
#define SNB_LLC_RFO             (1ULL << 8)

어느 것과 같아야 0x00010102하지만 일부 테이블로 확인하는 방법을 모르겠습니다.

그리고 이것은 그것이 어떻게 사용되는지에 대한 아이디어를 제공합니다 perf_events:

$ ak hw_cache_extra_regs linux-source-3.13.0/arch/x86/kernel/cpu/
linux-source-3.13.0/arch/x86/kernel/cpu/perf_event.c
50:u64 __read_mostly hw_cache_extra_regs
292:    attr->config1 = hw_cache_extra_regs[cache_type][cache_op][cache_result];

linux-source-3.13.0/arch/x86/kernel/cpu/perf_event.h
521:extern u64 __read_mostly hw_cache_extra_regs

linux-source-3.13.0/arch/x86/kernel/cpu/perf_event_intel.c
272:static __initconst const u64 snb_hw_cache_extra_regs
567:static __initconst const u64 nehalem_hw_cache_extra_regs
915:static __initconst const u64 slm_hw_cache_extra_regs
2364:       memcpy(hw_cache_extra_regs, nehalem_hw_cache_extra_regs,
2365:              sizeof(hw_cache_extra_regs));
2407:       memcpy(hw_cache_extra_regs, slm_hw_cache_extra_regs,
2408:              sizeof(hw_cache_extra_regs));
2424:       memcpy(hw_cache_extra_regs, nehalem_hw_cache_extra_regs,
2425:              sizeof(hw_cache_extra_regs));
2452:       memcpy(hw_cache_extra_regs, snb_hw_cache_extra_regs,
2453:              sizeof(hw_cache_extra_regs));
2483:       memcpy(hw_cache_extra_regs, snb_hw_cache_extra_regs,
2484:              sizeof(hw_cache_extra_regs));
2516:       memcpy(hw_cache_extra_regs, snb_hw_cache_extra_regs, sizeof(hw_cache_extra_regs));
$

memcpy작업은에서 수행됩니다 __init int intel_pmu_init(void) {... case:...}.

attr->config1조금 이상하다. 그러나 perf_event_attr(같은 linux-source-3.13.0/include/uapi/linux/perf_event.h파일)에 있습니다.

...
    union {
            __u64           bp_addr;
            __u64           config1; /* extension of config */                                                      
    };
    union {
            __u64           bp_len;
            __u64           config2; /* extension of config1 */
    };
...

커널 perf_events시스템에 int perf_pmu_register(struct pmu *pmu, const char *name, int type)(으로 정의 된 linux-source-3.13.0/kernel/events/core.c:) 호출로 등록됩니다 :

  • static int __init init_hw_perf_events(void)arch/x86/kernel/cpu/perf_event.c전화로 (파일 )perf_pmu_register(&pmu, "cpu", PERF_TYPE_RAW);

  • static int __init uncore_pmu_register(struct intel_uncore_pmu *pmu)전화로 (파일 arch/x86/kernel/cpu/perf_event_intel_uncore.c도 있습니다 arch/x86/kernel/cpu/perf_event_amd_uncore.c)ret = perf_pmu_register(&pmu->pmu, pmu->name, -1);

마지막으로 모든 이벤트는 하드웨어에서 발생하며 모든 것이 정상입니다. 그러나 여기에서주의 사항 수 : 왜 우리가해야합니까 LLC-loads에서 perf list가 아니라 ubox1 LLC-loads이러한 HW 이벤트이기 때문에, 그들은 actualy에서 온 ubox말이지?

그것은 perf유틸리티와 그 perf_evsel구조입니다. HW 이벤트를 요청 perf하면 원하는 프로세서를 이벤트로 정의하고 (기본값은 all) perf_evsel요청 된 이벤트 및 프로세서로 설정 한 다음 집계시 모든 프로세서의 카운터를 합 perf_evsel하거나 다른 통계를 수행합니다.

하나에서 볼 수 있습니다 tools/perf/builtin-stat.c:

/*
 * Read out the results of a single counter:
 * aggregate counts across CPUs in system-wide mode
 */
static int read_counter_aggr(struct perf_evsel *counter)
{
    struct perf_stat *ps = counter->priv;
    u64 *count = counter->counts->aggr.values;
    int i;

    if (__perf_evsel__read(counter, perf_evsel__nr_cpus(counter),
                           thread_map__nr(evsel_list->threads), scale) < 0)
            return -1;

    for (i = 0; i < 3; i++)
            update_stats(&ps->res_stats[i], count[i]);

    if (verbose) {
            fprintf(output, "%s: %" PRIu64 " %" PRIu64 " %" PRIu64 "\n",
                    perf_evsel__name(counter), count[0], count[1], count[2]);
    }

    /*
     * Save the full runtime - to allow normalization during printout:
     */
    update_shadow_stats(counter, count);

    return 0;
}

따라서 유틸리티의 perf경우 "싱글 카운터"는 perf_event_attrSW 및 HW 이벤트에 모두 맞는 일반적인 형식 인조차 아니므로 쿼리 이벤트입니다. 동일한 이벤트가 다른 장치에서 제공되어 집계 될 수 있습니다. .)

또한 알림 : struct perf_evsel1 만 포함 struct perf_evevent_attr하지만 필드도 있습니다 struct perf_evsel *leader;-중첩되어 있습니다. perf_events에 여러 개의 카운터를 함께 디스패치 할 수 있는 "(계층 적) 이벤트 그룹"의 기능이 있으므로 서로 비교할 수 있습니다. 확실하지가 독립적 이벤트와 작동 방법 kernel, core, ubox. 그러나이 중첩 perf_evsel은 그것입니다. 그리고 아마도 perf여러 이벤트에 대한 쿼리를 함께 관리하는 방법 일 것입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.