インターネット検索とack終了！いくつかの答えがあります。

しかし、まず質問の目的を再び明確にします。システムの独立したプロセスとそのパフォーマンスカウンタを明確に区別したいと思います。たとえば、プロセッサのコア、非コアデバイス（最近の学習）、プロセッサのカーネルまたはユーザーアプリケーション、バス（=バスコントローラ）、ハードドライブは、すべてクロックによって同期されない独立したプロセスです。今日では、すべてプロセス監視カウンタ（PMC）が装備されています。カウンターがどのプロセスから出てくるのか知りたいです。 （これはインターネット検索にも役立ちます。物事の「サプライヤー」をよりよく確認できます。）

また、検索用機器: Ubuntu 14.04、linux 3.13.0-103-generic、プロセッサIntel(R) Core(TM) i5-3317U CPU @ 1.70GHz( には/proc/cpuinfo2つの物理コアと4つの仮想コアがあります。ここでは物理的な問題があります)。

質問に関連する用語、内容

インテルでは：

• プロセッサは1つの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は、残りの部分に[raw 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 */
  

  （私のエイリアスで、Debianの名前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 Software Developer Manual Volume 3Bの「事前定義されたアーキテクチャパフォーマンスイベント」、18.2.1.2と呼ぶことから来ています。マニュアルの「18.1 性能監視の概要」では、次のように説明します。

パフォーマンスモニタリング機能の2番目のカテゴリは、アーキテクチャパフォーマンスモニタリングと呼ばれます。このクラスは、同じ計算および割り込みベースのイベントサンプリングの使用法と、より少ない数の使用可能なイベントセットをサポートします。アーキテクチャパフォーマンスイベントの可視的な動作は、プロセッサの実装全体で一貫しています。 CPUID.0AH を使用してスキーマのパフォーマンス監視機能の可用性を列挙します。これらのイベントはセクション18.2で議論されています。

- 別のタイプは次のとおりです。

Intel Core Single-CoreおよびIntel Core Duoプロセッサから、パフォーマンス監視機能には2つのカテゴリがあります。最初のカテゴリは、計算または割り込みベースのイベントサンプリングを使用してパフォーマンスを監視するイベントをサポートします。これらのイベントはアーキテクチャには関係なく、プロセッサモデルによって異なります。

これらのイベントは実際には基本的な「生」ハードウェアイベントへのリンクであり、ユーティリティを介し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] =
{...}

——砂橋にはどれを使うべきですか？

そのうちの1つである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));
$

smemcpyはで完了しました__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-loadsinperf 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複数のイベントに対するクエリが管理される方法です。