perf_eventsリストのカーネルPMUイベントは何ですか?


11

Linuxで監視できるものを検索しperf_eventsも、何Kernel PMU eventが見つからないのですか?すなわち、とのようなショーイベント:perf version 3.13.11-ckt39perf 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アイテムです。

perf wikiチュートリアルBrendan Greggのページから、次のことがわかります

  • Tracepoints最も明確です-これらは、カーネルソース上のマクロであり、監視のためのプローブポイントを作成します。これらはftraceプロジェクトで導入され、現在すべての人が使用しています
  • Software カーネルの低レベルのカウンターといくつかの内部データ構造です(したがって、これらはトレースポイントとは異なります)
  • Hardware eventすべてのアーキテクチャで見つかる非常に基本的なCPUイベントであり、カーネルによって簡単にアクセスできます
  • Hardware cache eventニックネームですRaw hardware event descriptor-次のように機能します

    わかったように、Raw hardware event descriptor(マイクロ?)アーキテクチャ固有のイベントはHardware event、に限定されます。イベントは、プロセッサモニタリングユニット(PMU)または特定のプロセッサの他の特定の機能から発生するため、一部のマイクロアーキテクチャでのみ利用できます(「アーキテクチャ」は「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アクセスを容易にするためにそれをLinux に接続します

    -私が間違っている場合は修正してください(不思議なことにすべてHardware cache eventが- something-loadsまたはsomething-misses-実際のプロセッサのキャッシュに非常に似ています。)

  • 今、 Hardware breakpoint

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

    ハードウェア機能とは、おそらくほとんどの最新のアーキテクチャに共通であり、デバッガーのブレークポイントとして機能しますか?(とにかくそれはグーグル可能です)

  • 最後に、Kernel PMU event私はグーグルで管理することができません。

    また、Brendanのパフォーマンスページのイベントのリストにも表示されないので、新しいですか。

    多分それは特にPMUからのハードウェアイベントへの単なるニックネームですか?(アクセスを簡単にするために、ニックネームに加えて、イベントのリストに別のセクションがあります。)実際、Hardware cache eventsCPUのキャッシュからのハードウェアイベントKernel PMU eventへのニックネームであり、PMUイベントへのニックネームですか?(なぜそれを呼び出さないの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は「カーネルのパフォーマンス監視ユニット」のようなものです。)

PS

より良いコンテキストを提供するためにperf listKernel PMU eventsとHardware cache eventsの完全なリストとその他をスキップした非特権実行(トレースポイントは表示されませんが、それらの1374はすべてそこにあります):

$ 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-ingは終了しました!いくつか答えがあります。

ただし、最初に、質問の目的をもう少し明確にします。システム内の独立したプロセスとそのパフォーマンスカウンターを明確に区別したいのです。たとえば、プロセッサのコア、アンコアデバイス(それについて最近学習)、プロセッサ上のカーネルまたはユーザーアプリケーション、バス(=バスコントローラ)、ハードドライブはすべて独立したプロセスであり、クロックによって同期されていません。そして今日ではおそらくそれらすべてに何らかのプロセス監視カウンター(PMC)があります。カウンターがどのプロセスから来たかを知りたいのですが。(それはグーグルで役に立ちます:物事の「ベンダー」はそれをよりよくゼロにします。)

また、検索に使用ギア:Ubuntu 14.04linux 3.13.0-103-generic、プロセッサIntel(R) Core(TM) i5-3317U CPU @ 1.70GHz(から/proc/cpuinfo-物理的な問題ここでは、2つの物理コアと4つの仮想を持っています)。

用語、問題に関連するもの

インテルから:

  • プロセッサは、あるcoreデバイス(それは1デバイス/プロセスだ)との束uncore機器coreプログラム(クロック、ALU、レジスタなど)を実行するもので、uncore本当の理由(デバイスが高速かつ低レイテンシのために近くのプロセッサに、ダイの上に置かれ「メーカーができるから」です); 私が理解したように、それは基本的にPCマザーボードのようなノースブリッジとキャッシュです。AMDは実際にこれらのデバイスをinstead ofNorthBridgeをアンコアと呼んでいます。

  • 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つのコア、つまり2つのLLCと2を持っていuboxます。

  • プロセッサ監視ユニット(PMU)は、プロセッサの動作を監視し、それらをプロセッサ監視カウンタ(PMC)に記録する個別のデバイスです(キャッシュミス、プロセッササイクルなどをカウントします)。彼らは上に存在するcoreuncoreデバイス。これらcorerdpmc(PMCの読み取り)命令でアクセスされます。uncoreこれらのデバイスは、手で、実際のプロセッサに依存するため、ビアモデル固有レジスタ(MSR)を介してアクセスされているrdmsr(天然)

    明らかに、それらのワークフローは、レジスタのペアを介して行われます。1つのレジスタは、カウンタがカウントするイベントを設定します。2つのレジスタは、カウンタの値です。カウンタは、1つだけでなく、一連のイベントの後に増分するように構成できます。+これらのカウンターのオーバーフローに気づくいくつかの中断/技術があります。

  • インテルの「IA-32ソフトウェア開発者向けマニュアルVol 3B」の章18「パフォーマンスモニタリング」でさらに多くの情報を見つけることができます。

    また、これらのuncorePMCのバージョン「Architectural Performance Monitoring Version 1」のMSRのフォーマット(マニュアルにはバージョン1〜4があり、どちらが私のプロセッサかわかりません)については、「図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(ファイルlinux-source-3.13.0/include/uapi/linux/perf_event.h)として定義され、その主な部分はおそらく__u64 configフィールドです-CPU固有のイベント定義(これらのIntelの図で説明されている形式の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 */
    

    (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(ファイル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はプロセッサ固有のキャッシュデバイス(uboxIntelのuncoreデバイス)のイベントへの「ショートカット」であり、プロトコルを介してアクセスできますRaw hardware event descriptor。そしてHardware event私が理解しているように、coreデバイスからのイベントに名前を付けるアーキテクチャ内でより安定しています。私のカーネル3.13には、他のいくつかのuncoreイベントやカウンターへの「ショートカット」はありません。すべての残りの部分- SoftwareとはTracepoints-カーネルのイベントです。

    のは同じプロトコルを介してアクセスされるcoreのでしょうか。彼らはそうではないかもしれません-カウンター/ PMUが上にあるので、おそらくそれは異なってアクセスされます。たとえば、にアクセスするの代わりに、その命令を使用します。しかし、それはそれほど重要ではありません。Hardware eventRaw hardware event descriptorcorerdpmurdmsruncore

  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 eventIntelがIA-32ソフトウェア開発者向けマニュアルVol 3Bの「定義済みのアーキテクチャパフォーマンスイベント」18.2.1.2と呼んでいるものに由来するようです。また、マニュアルの「18.1パフォーマンスモニタリングの概要」では、次のように説明しています。

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

-他のタイプは:

インテルCore Soloおよびインテル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ミス」の「表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] =
{...}

-砂の橋にはどちらがいいですか?

これらの1つ- snb_hw_cache_extra_regs[LL][OP_WRITE][RESULT_ACCESS]はで埋められ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));
$

memcpysの中で行われています__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-loadsperf listはなくubox1 LLC-loads、これらはHWイベントであり、彼らはactualyから来ているので、uboxES?

これは、perfユーティリティとそのperf_evsel構造の問題です。HWイベントを要求するときに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、SWとHWの両方のイベントに当てはまる一般的な形式のでもありません。これは、クエリのイベントです。同じイベントが異なるデバイスから発生し、それらが集約されます。)

また、通知:struct perf_evsel1のみが含まれstruct perf_evevent_attrていますが、フィールドもありますstruct perf_evsel *leader;-ネストされています。の「(階層的)イベントグループ」にはperf_events、多数のカウンタを一緒にディスパッチして、それらを相互に比較できるなどの機能があります。それはから独立したイベントでどのように動作するかわかりませんkernelcoreubox。しかし、この入れ子perf_evselはそれだけです。そしておそらく、それperfが複数のイベントのクエリを一緒に管理する方法です。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.