인터넷 검색과 ack끝! 몇 가지 답이 있습니다.

하지만 먼저 질문의 목적을 다시 명확히 하겠습니다. 시스템의 독립적인 프로세스와 해당 성능 카운터를 명확하게 구분하고 싶습니다. 예를 들어, 프로세서의 코어, 비코어 장치(최근 학습), 프로세서의 커널 또는 사용자 애플리케이션, 버스(=버스 컨트롤러), 하드 드라이브는 모두 클럭에 의해 동기화되지 않는 독립적인 프로세스입니다. 요즘에는 모두 프로세스 모니터링 카운터(PMC)를 갖추고 있을 것입니다. 카운터가 어떤 프로세스에서 나오는지 알고 싶습니다. (이것은 인터넷 검색에도 도움이 됩니다. 사물의 "공급자"를 더 잘 확인할 수 있습니다.)

또한 검색용 장비: Ubuntu 14.04, linux 3.13.0-103-generic, 프로세서 Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz( 에서는 /proc/cpuinfo2개의 물리적 코어와 4개의 가상 코어가 있습니다. 여기에서는 물리적인 문제가 있습니다).

질문에 관련된 용어, 내용

인텔에서:

• 프로세서는 하나의 core장치(1개의 장치/프로세스)이자 여러 개의 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마지막 레벨 캐시(LLC, RAM에 도달하기 전 마지막 레벨 캐시)를 관리하는 장치입니다. 따라서 2개의 LLC와 2개의 코어가 있습니다 ubox.

• PMU(프로세서 모니터링 장치)는 프로세서의 작동을 모니터링하고 이를 PMC(프로세서 모니터링 카운터)에 기록하는 별도의 장치입니다(캐시 누락, 프로세서 주기 등 계산 core) uncore. (PMC 읽기) 명령을 core통해 rdpmc액세스 됩니다. uncore이러한 장치는 실제 프로세서에 의존하므로 MSR(모델별 레지스터)을 통해 (자연스럽게) 액세스할 수 있습니다 rdmsr.

  분명히 그들의 작업 흐름은 레지스터 쌍을 통해 수행됩니다. 카운터가 계산하는 1개의 레지스터 세트, 2개의 레지스터는 카운터의 값이며 단지 1개가 아닌 여러 이벤트 후에 증가하도록 구성할 수 있습니다. 이러한 카운터 오버플로를 알아차리는 인터럽트/기술이 있습니다.

• 자세한 내용은 Intel의 "IA-32 소프트웨어 개발자 매뉴얼 Vol 3B"의 18장 "성능 모니터링"에서 확인할 수 있습니다.

  또한 "Architecture Performance Monitoring Version 1" 버전 uncore(설명서에 버전 1~4가 있는데 어느 것이 내 프로세서인지는 모르겠습니다)의 이러한 PMC에 대한 MSR의 특정 형식은 "그림 18- 1. 레이아웃" IA32_PERFEVTSELx MSR "(내 페이지 18-3) 및 "18.2.1.2 미리 정의된 아키텍처 성능 이벤트" 및 "표 18-1 미리 정의된 아키텍처 성능 이벤트에 대한 UMask 및 이벤트 선택 코딩" 섹션을 보여줍니다. Hardware event에 표시된 이벤트 perf list.

Linux 커널에서:

• 커널에는 소프트웨어(커널)와 하드웨어 모두에서 성능 카운터를 관리하기 위한 시스템(추상화/계층)이 있으며, 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-grepackack

  커널의 소스 코드에서 우리는 "시스템에서 발견된 모든 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(file linux-source-3.13.0/tools/perf/util/evsel.{h,c})를 나타냅니다. 구조에는 필드가 있지만 struct perf_event_attr attr;유틸리티와 유사한 struct cpu_map *cpus;방법 도 있습니다. perf전체 또는 특정 CPU의 필드에 이벤트를 할당합니다 .

답변

1. 실제로 이는 캐시 장치(인텔 장치) Hardware cache event이벤트에 대한 "바로 가기"이며, 프로세서별로 다르며 프로토콜을 통해 액세스할 수 있습니다. 그리고 내가 아는 한 그것은 장치의 이벤트 이름을 지정하므로 아키텍처 내에서 더 안정적입니다. 내 커널에는 다른 이벤트와 카운터에 대한 "바로 가기"가 없습니다. 나머지는 모두 커널 이벤트입니다.uboxuncoreRaw hardware event descriptorHardware eventcore3.13uncoreSoftwareTracepoints

   동일한 프로토콜을 core통해 액세스 되는지 궁금합니다 . 아마도 그렇지 않을 것입니다. 카운터/PMU가 켜져 있기 때문에 다르게 액세스되었을 수도 있습니다. 예를 들어, access 대신 해당 지시문을 사용하십시오 . 그러나 이는 그다지 중요하지 않습니다.Hardware eventRaw hardware event descriptorcorerdpmurdmsruncore

2. Kernel PMU event이벤트 만 sysfs. 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 event및Hardware cache event

분명히 이것은 Hardware eventIntel이 IA-32 소프트웨어 개발자 매뉴얼 볼륨 3B의 "사전 정의된 아키텍처 성능 이벤트", 18.2.1.2라고 부르는 것에서 나온 것입니다. 매뉴얼의 "18.1 성능 모니터링 개요"에서는 다음과 같이 설명합니다.

성능 모니터링 기능의 두 번째 범주는 아키텍처 성능 모니터링이라고 합니다. 이 클래스는 동일한 계산 및 인터럽트 기반 이벤트 샘플링 사용법은 물론 더 적은 수의 사용 가능한 이벤트 세트를 지원합니다. 아키텍처 성능 이벤트의 가시적 동작은 프로세서 구현 전반에 걸쳐 일관됩니다. CPUID.0AH를 사용하여 스키마 성능 모니터링 기능의 가용성을 열거합니다. 이러한 이벤트는 섹션 18.2에서 논의됩니다.

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

Intel Core Single-Core 및 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

--는 H16진수를 나타냅니다. 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] =
{...}

——모래교에는 어느 것을 사용해야 합니까?

그 중 하나인 snb_hw_cache_extra_regs[LL][OP_WRITE][RESULT_ACCESS]--fill 은 SNB_DMND_WRITE|SNB_L3_ACCESS위의 def-s에서 유래되었습니다.

#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));
$

s 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-loadsin perf list과 not 을 갖고 있는지 알 수 있습니다. ubox1 LLC-loads이는 하드웨어 이벤트이고 실제로 uboxes에서 발생하기 때문입니다.

perf유틸리티와 해당 구조에 대한 내용은 다음과 같습니다 perf_evsel. 하드웨어 이벤트를 요청할 때 해당 이벤트를 가져올 프로세서를 정의하고(기본값은 모두) 요청한 이벤트와 프로세서로 설정한 다음 집계 할 perf때 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_attr소프트웨어와 하드웨어 이벤트 모두에 적합한 일반적인 형식이며 쿼리하는 이벤트입니다. 동일한 이벤트가 다른 장치에서 올 수 있으며 다시 집계되었습니다.)

또한 참고: struct perf_evsel1 개만 포함되어 있지만 struct perf_evevent_attr필드도 포함되어 있습니다 struct perf_evsel *leader;. 중첩되어 있습니다. "(계층적) 이벤트 그룹"에는 perf_events여러 카운터를 함께 파견하여 서로 비교할 수 있는 기능이 있습니다 . kernel, , 의 core독립적인 이벤트를 어떻게 처리하는지 잘 모르겠습니다 ubox. 하지만 이번 중첩은 그게 전부입니다 perf_evsel. 그리고 아마도 이것이 perf여러 이벤트에 대한 쿼리가 관리되는 방식일 것입니다.