Beranda>Terkait pemrograman>Pembangun Kekuatan
Unduh

Alat Analisis Daya/Kinerja Terbuka (Oppat)

Daftar isi

  • Perkenalan
  • Jenis Data yang Didukung
  • Visualisasi Oppat
    • Fitur Bagan
    • jenis bagan
  • Pengumpulan Data untuk Oppat
  • Dukungan Data PCM
  • Membangun Oppat
  • Menjalankan oppat
  • Acara turunan
  • Menggunakan antarmuka GUI browswer
  • Batasan

Perkenalan

Open Power/Performance Analysis Tool (OPPAT) adalah alat cross-OS, kekuatan lintas-arsitektur dan alat analisis kinerja.

  • Cross-OS: Mendukung file Windows ETW Trace dan file jejak Linux/Android/Trace-CMD
  • Cross-Architecture: Mendukung acara perangkat keras Intel and Arm Chips (menggunakan perf dan/atau PCM)

Halaman web proyek adalah https://patinnc.github.io

Repo kode sumber adalah https://github.com/patinnc/oppat

Saya telah menambahkan sistem operasi (OS_VIEW) ke fitur diagram blok CPU. Ini berdasarkan halaman Brendan Gregg seperti http://www.brendangregg.com/linuxperf.html. Berikut adalah beberapa contoh data untuk menjalankan versi lama Geekbench v2.4.2 (Kode 32bit) di ARM 64BIT UBUNTU MATE V18.04.2 Raspberry Pi 3 B+, 4 Arm Cortex A53 CPU:

  • Video perubahan pada diagram blok OS_VIEW dan ARM A53 yang menjalankan Geekbench: Geekbench on Arm - The Movie V3
    • Ada beberapa slide pengantar untuk mencoba dan menjelaskan tata letak OS_VIEW dan CPU_DIAGRAM dan kemudian 1 slide yang menunjukkan hasil per masing -masing dari 30 subtests
  • File Excel dari data dalam film: File Excel dari Geekbench the Movie
  • HTML data dalam film ... lihat Geekbench v2.4.2 pada 4 Core ARM Cortext A53 dengan OS_VIEW, Diagram CPU.
  • Dashboard PNG untuk semua 30 fase diurutkan dengan meningkatkan instruksi/detik ... lihat ARM CORTEX A53 Raspberry Pi 3 dengan CPU Diagram 4-Core Chip Dashboard Menjalankan Geekbench.

Berikut adalah beberapa contoh data untuk menjalankan tolok ukur spin saya (uji bandwidth memori/cache, tes 'spin' Keep-CPU-Busy) pada raspberry Pi 3 B+ (Cortex A53) CPU:

  • Video perubahan pada OS_VIEW dan ARM A53 CPU Block Diagram Running Spin: Putar lengan A53 - filmnya
    • Ada beberapa slide pengantar untuk mencoba dan menjelaskan grafik OS_VIEW dan tata letak CPU_DIAGRAM, slide yang menunjukkan pada saat itu (dalam detik) setiap sub-tes ditampilkan (sehingga Anda dapat pergi ke T = x detik untuk langsung ke sub-tes tersebut) dan kemudian satu slide untuk masing-masing subtestis 5 subtestis untuk masing-masing subtest.
  • File Excel dari data dalam film: File Excel dari Geekbench the Movie
  • HTML data dalam film ... lihat ARM Cortex A53 Raspberry Pi 3 dengan diagram CPU 4-Core Chip Running Spin Benchmark.
  • Dashboard PNG untuk semua 5 fase diurutkan dengan meningkatkan instruksi/detik ... lihat ARM CORTEX A53 Raspberry Pi 3 dengan CPU Diagram 4-Core Chip Dashboard Menjalankan Benchmark Spin.

Berikut adalah beberapa contoh data untuk menjalankan Geekbench di Haswell CPU:

  • Video perubahan pada diagram blok CPU OS_VIEW dan Haswell menjalankan Geekbench: Geekbench - film v4
    • Ada beberapa slide pengantar untuk mencoba dan menjelaskan grafik OS_VIEW dan tata letak CPU_DIAGRAM, slide yang menunjukkan pada saat itu (dalam detik) setiap sub-tes ditampilkan (sehingga Anda dapat pergi ke T = x dt
  • File Excel dari data dalam film: File Excel dari Geekbench the Movie
  • HTML data dalam film ... lihat Intel Haswell dengan CPU Diagram 4-CPU Chip Running Geekbench.
  • Dashboard PNG untuk semua 50 fase diurutkan dengan meningkatkan UOPS pensiunan/detik ... lihat dasbor Intel Haswell dengan diagram CPU 4-core chip dashboard menjalankan Geekbench.

Berikut adalah beberapa data untuk menjalankan patokan 'spin' saya dengan 4 sub-tes di Haswell CPU:

  • Subtest 1 adalah tes bandwidth memori baca. Blok L2/L3/memori sangat digunakan dan terhenti selama pengujian. UPS/siklus tikus rendah karena tikus sebagian besar terhenti.
  • Subtest ke -2 adalah tes bandwidth baca L3. Memori BW sekarang rendah. Blok L2 & L3 sangat digunakan dan terhenti selama pengujian. UPS/siklus tikus lebih tinggi karena tikus kurang terhenti.
  • Subtest ke -3 adalah tes bandwidth baca L2. L3 dan memori BW sekarang rendah. Blok L2 sangat digunakan dan terhenti selama pengujian. UPS/siklus tikus bahkan lebih tinggi karena tikus bahkan kurang terhenti.
  • Subtest ke -4 adalah tes putaran (hanya tambahkan loop). L2, L3 dan memori BW mendekati nol. UPS/siklus tikus adalah sekitar 3,3 UOPS/siklus yang mendekati 4 UOPS/siklus MAX mungkin.
  • Video perubahan pada diagram blok CPU Haswell yang menjalankan 'spin' dengan analisis. Melihat Spin - filmnya
  • File Excel dari data dalam film: File Excel dari Spin the Movie
  • HTML data dalam film ... lihat Intel Haswell dengan diagram CPU 4-cpu chip yang menjalankan benchmark spin.

Intel Haswell dengan koleksi data diagram CPU adalah untuk chip Intel 4-CPU, OS Linux, file HTML dengan peristiwa 50+ HW melalui pengambilan sampel perf dan data lainnya yang dikumpulkan. Fitur CPU_Diagram:

  • Mulailah dengan diagram blok SVG dari wikichip.org (digunakan dengan izin),
  • Lihatlah kendala sumber daya (seperti Max BW, Max Bytes/Cycle di berbagai jalur, siklus minimum/UOP, dll),
  • Hitung metrik untuk penggunaan sumber daya
  • Di bawah ini adalah tabel uji bandwidth membaca memori yang menampilkan info penggunaan sumber daya dalam sebuah tabel (bersama dengan perkiraan apakah CPU terhenti karena penggunaannya). Tabel HTML (tetapi bukan PNG) memiliki info popup saat Anda melayang di atas bidang. Tabel menunjukkan bahwa:
    • Inti macet pada bandwidth memori pada 55% dari maksimal 25,9 GB/s BW. Ini adalah uji memori BW
    • Superqueue (SQ) penuh (54,5% untuk Core0 dan 62,3% Core1) dari siklus (jadi lebih banyak permintaan L2 tidak dapat ditangani)
    • Line Fill Buffer FB penuh (30% dan 51%) sehingga garis tidak dapat dipindahkan ke L1D dari L2
    • Hasilnya adalah bahwa backend terhenti (88% dan 87%) dari siklus tidak ada UOPS yang pensiun.
    • UOPS tampaknya berasal dari detektor aliran loop (karena siklus LSD/UOP hampir sama dengan tikus UOPS/siklus.
    • bidikan layar dari tabel BW Diagram CPU Haswell
  • Di bawah ini adalah tabel L3 Read Bandwidth Test.
    • Sekarang memori BW dan L3 Miss Bytes/Cycle sekitar nol.
    • SQ kurang macet (karena kami tidak menunggu memori).
    • Byte/siklus transaksi L2 sekitar 2x lebih tinggi dan sekitar 67% dari maksimal 64 byte/siklus.
    • UOPS_RETIRED_STALLS/CYCLE telah turun menjadi 66% dari kios uji MEM BW sebesar 88%.
    • Kios penyangga mengisi sekarang lebih dari 2x lebih tinggi. UPS masih berasal dari LSD.
    • bidikan layar dari diagram CPU Haswell L3 BW Table
  • Di bawah ini adalah tabel L2 Read Bandwidth Test.
    • L2 melewatkan byte/siklus jauh lebih rendah dari uji L3.
    • UOPS_RETIRED% terhenti sekarang sekitar setengah dari tes L3 pada 34% dan kios FB juga sekitar 17%.
    • UOP masih berasal dari LSD.
    • Bidikan layar dari diagram CPU Haswell L2 BW Table
  • Di bawah ini adalah tabel uji putaran (tanpa beban, cukup tambahkan dalam satu loop).
    • Sekarang ada hanya sekitar nol kios subsistem memori.
    • UOPS berasal dari Decode Stream Buffer (DSB).
    • Rat Retired_uops/siklus pada 3,31 siklus/UOP mendekati maks kemungkinan 4.0 UOPS/siklus.
    • Tikus pensiunan_uops %macet cukup rendah pada %8.
    • bidikan layar dari tabel spin diagram CPU Haswell

Saat ini saya hanya memiliki film cpu_diagram untuk Haswell dan ARM A53 (karena saya tidak memiliki sistem lain untuk diuji) tetapi seharusnya tidak sulit untuk menambahkan diagram blok lainnya. Anda masih mendapatkan semua grafik tetapi bukan CPU_Diagram.

Di bawah ini adalah salah satu grafik Oppat. Bagan 'CPU_BUSY' menunjukkan apa yang berjalan pada setiap CPU dan peristiwa yang terjadi pada setiap CPU. Misalnya, lingkaran hijau menunjukkan benang spin.x yang berjalan pada CPU 1. Lingkaran merah menunjukkan beberapa peristiwa yang terjadi pada CPU1. Bagan ini dimodelkan setelah grafik Kernelshark Trace-CMD. Info lebih lanjut tentang grafik CPU_BUSY ada di bagian jenis bagan. Kotak Callout menunjukkan data acara (termasuk CallStack (jika ada)) untuk acara di bawah kursor. Sayangnya tangkapan layar Windows tidak menangkap kursor. bidikan layar dari bagan sibuk CPU

Berikut adalah beberapa file HTML sampel. Sebagian besar file untuk interval ~ 2 yang lebih pendek tetapi beberapa kali 'penuh' 8 detik. File tidak akan memuat langsung dari repo tetapi mereka akan memuat dari halaman web proyek: https://patinnc.github.io

  • Intel Haswell dengan CPU Diagram 4-CPU Chip, Linux OS, File HTML dengan 50+ HW Event melalui Perf Sampling atau
  • Chip Intel 4-CPU, OS Windows, file HTML dengan 1 HW Event melalui Xperf Sampling atau
  • penuh ~ 8 detik chip 4-cpu intel, windows os, file html dengan pcm dan sampling xperf atau
  • Chip Intel 4-CPU, OS Linux, file HTML dengan 10 HW Event dalam 2 grup multiplexed.
  • Chip ARM (Broadcom A53), file HTML Raspberry PI3 Linux dengan 14 acara HW (untuk CPI, L2 Misses, MEM BW dll dalam 2 grup multiplexed).
  • 11 MB, Versi Lengkap dari Chip ARM (Broadcom A53) di atas, file HTML Raspberry PI3 Linux HTML dengan 14 acara HW (untuk CPI, L2 Misses, MEM BW dll dalam 2 grup multiplexed).

Beberapa file di atas adalah ~ interval 2 detik yang diekstraksi dari ~ 8 detik berjalan panjang. Inilah 8 detik penuh:

  • Sampel Linux Linux Linux Linux lengkap lengkap file terkompresi HTML di sini untuk file yang lebih lengkap. File melakukan JavaScript Zlib mendekompres data grafik sehingga Anda akan melihat pesan yang meminta Anda untuk menunggu (sekitar 20 detik) selama dekompresi.

Data Oppat didukung

  • Linux Perf dan/atau Trace-CMD Performance Files (baik file biner dan teks),
    • output stat perf juga diterima
    • Data Intel PCM,
    • Data lain (diimpor menggunakan skrip LUA),
    • Jadi ini harus berfungsi dengan data dari Linux atau Android biasa
    • Saat ini untuk data Perf dan Trace-CMD, Oppat memerlukan file teks biner dan pasca-diproses dan ada beberapa batasan pada baris perintah 'Rekam' dan baris perintah 'Laporan TRACE/TRACE-CMD'.
    • Oppat dapat dibuat untuk hanya menggunakan file output teks perf/trace-CMD tetapi saat ini diperlukan file biner dan teks
  • Data Windows ETW (dikumpulkan oleh Xperf dan dibuang ke teks) atau data PCM Intel,
  • Data kekuatan atau kinerja sewenang -wenang didukung menggunakan skrip LUA (jadi Anda tidak perlu mengkompilasi ulang kode C ++ untuk mengimpor data lain (kecuali kinerja LUA menjadi masalah))
  • Baca file data di Linux atau Windows terlepas dari dari mana file-file tersebut berasal (jadi baca file perf/trace-CMD pada file teks Windows atau ETW di Linux)

Visualisasi Oppat

Berikut adalah beberapa sampel lengkap file html visualzasi: file html sampel windows atau file html sampel linux ini. Jika Anda berada di repo (bukan situs web Proyek GitHub.io), Anda harus mengunduh file dan kemudian memuatnya ke browser Anda. Ini adalah file web mandiri yang dibuat oleh Oppat yang bisa, misalnya, diemail ke orang lain atau (seperti di sini) diposting di server web.

Oppat Viz bekerja lebih baik di Chrome daripada Firefox terutama karena zoom menggunakan gulir jari TouchPad 2 berfungsi lebih baik pada Chrome.

Oppat memiliki 3 mode visualisasi:

  1. Mekanisme bagan yang biasa (di mana oppat backend membaca file data dan mengirim data ke browser)
  2. Anda juga dapat membuat halaman web mandiri yang setara dengan 'mekanisme bagan reguler' tetapi dapat dipertukarkan dengan pengguna lain ... halaman web mandiri memiliki semua skrip dan data bawaan sehingga dapat diemail ke seseorang dan mereka dapat memuatnya di browser mereka. Lihat file html di sample_html_files yang dirujuk di atas dan (untuk versi yang lebih panjang dari lnx_mem_bw4) Lihat file terkompresi sample_html_files/lnx_mem_bw4_full.html
  3. Anda dapat 'menampung' file data json dan kemudian-memuat file nanti. File JSON yang disimpan adalah data yang perlu dikirim oleh Oppat ke browser. Ini menghindari membaca ulang file input perf/xperf tetapi tidak akan mengambil perubahan yang dibuat di charts.json. File HTML lengkap yang dibuat dengan opsi --web_file hanya sedikit lebih besar dari file - -Save. Mode-Save/-Load membutuhkan Building Oppat. Lihat file sampel 'disimpan' di sampel_data_json_files subdir.

Yaitu info umum

  • Bagan semua data di browser (di Linux atau Windows)
  • Bagan didefinisikan dalam file JSON sehingga Anda dapat menambahkan acara dan grafik tanpa mengompilasi ulang oppat
  • Antarmuka browser seperti Windows WPA (Navbar di sebelah kiri).
    • Di bawah ini menunjukkan Navbar kiri (menu geser sisi kiri).
    • Screenshot Bar Nav
    • Bagan dikelompokkan berdasarkan kategori (GPU, CPU, Power, dll)
      • Kategori didefinisikan dan ditetapkan dalam input_files/charts.json
    • Bagan dapat disembunyikan atau ditampilkan secara selektif dengan mengklik bagan di navbar.
    • melayang di atas judul grafik di menu Nav kiri menggulir grafik itu ke tampilan
  • Data dari satu grup file dapat diplot di samping grup yang berbeda
    • Jadi Anda bisa mengatakan, bandingkan Kinerja Perf Linux vs Windows ETW Run
    • Di bawah bagan Tampilkan Linux vs Windows Power Usage:
    • penggunaan daya
      • Saya hanya memiliki akses ke daya baterai di Linux dan Windows.
      • Banyak situs memiliki data daya yang jauh lebih baik (tegangan/arus/daya pada tingkat MSEC (atau lebih baik)). Akan mudah untuk menggabungkan jenis data daya ini (seperti dari Kratos atau MDP Qualcomm) tetapi saya tidak memiliki akses ke data.
    • atau bandingkan 2 berjalan berbeda pada platform yang sama
    • Tag grup file (file_tag) diawali dengan judul untuk membedakan grafik
      • A 'Tag' didefinisikan dalam file Dir's File_List.json dan/atau input_files/input_data_files.json
      • Input_files/input_data_files.json adalah daftar semua Dirs Data Oppat (tetapi pengguna harus mempertahankannya).
    • Grafik dengan judul yang sama diplot satu demi satu untuk memungkinkan perbandingan mudah

Fitur bagan:

  • melayang di atas bagian dari garis bagan menunjukkan titik data untuk garis itu pada titik itu

    • Ini tidak berfungsi untuk garis vertikal karena mereka hanya menghubungkan 2 poin ... hanya potongan horizontal dari setiap baris yang dicari untuk nilai data
    • Di bawah ini adalah tangkapan layar melayang di atas acara. Ini menunjukkan waktu relatif dari acara (CSWTICH), beberapa info seperti proses/pid/tid dan nomor baris dalam file teks sehingga Anda bisa mendapatkan info lebih lanjut.
    • bidikan layar melayang di atas acara
    • Di bawah ini adalah tangkapan layar yang menunjukkan info CallStack (jika ada) untuk acara.
    • bidikan layar acara dengan callstack

  • zooming

    • Zooming tak terbatas ke tingkat nanosec dan memperbesar kembali.
      • Mungkin ada pesanan lebih besar poin untuk plot daripada piksel sehingga lebih banyak data ditampilkan saat Anda memperbesar.
      • Di bawah ini adalah tangkapan layar yang menunjukkan pembesaran ke tingkat mikrodetik. Ini menunjukkan acara CallStack untuk SCHART_SWITCH di mana spin.x diblokir dengan melakukan operasi pemetaan memori dan menganggur. Bagan 'CPU sibuk' menunjukkan 'Going Idle' sebagai kosong.
      • bidikan layar zoom di level mikrodetik .
    • Bagan dapat diperbesar secara individual atau grafik dengan file_tag yang sama dapat ditautkan sehingga zooming/panning 1 grafik mengubah interval semua grafik dengan file_tag yang sama
      • Gulir ke bagian bawah navbar kiri dan klik 'Zoom/Pan: Unlinked'. Ini akan mengubah item menu menjadi 'Zoom/Pan: Linked'. Ini akan memperbesar/menggerakkan semua grafik dalam grup file ke zoom/PAN absolute time terbaru. Ini akan membutuhkan waktu untuk menggambar ulang semua grafik.
        • Awalnya setiap bagan ditarik menampilkan semua data yang tersedia. Jika grafik Anda berasal dari sumber yang berbeda maka T_Begin dan T_end (untuk bagan dari sumber yang berbeda) mungkin berbeda.
        • Setelah operasi Zoom/PAN dilakukan semua dan menghubungkan berlaku maka semua grafik dalam grup file akan memperbesar/PAN ke interval absolut yang sama.
          • Inilah sebabnya mengapa 'jam' yang digunakan untuk setiap sumber harus sama.
          • Oppat bisa menerjemahkan dari satu jam ke jam lain (seperti antara getTime (clock_monotonic) dan getTimeOfday ()) tetapi logika itu
        • Setiap flamegraph untuk interval selalu diperbesar ke interval 'bagan memiliki terlepas dari status penghubung.
    • Anda dapat memperbesar/keluar oleh:
      • Zoom in: Mouse Wheel secara vertikal di area grafik. Bagan memperbesar waktu di tengah grafik.
        • Di laptop saya, ini sedang menggulir 2 jari secara vertikal di touchpad
      • Zoom In: Mengklik di bagan dan menyeret mouse ke kanan dan melepaskan mouse (bagan akan memperbesar ke interval yang dipilih)
      • Zoom Out: Mengklik pada grafik dan menyeret mouse ke kiri dan melepaskan mouse akan meluncur dalam jenis berbanding terbalik dengan berapa banyak bagan yang Anda pilih. Artinya, jika Anda meninggalkan seret hampir seluruh area bagan maka bagan akan meluncur kembali ~ 2x. Jika Anda baru saja meninggalkan seret interval kecil maka bagan akan memperbesar ~ sepenuhnya.
      • Zoom Out: Di laptop saya, melakukan gulungan vertikal 2 touchpad 2 jari ke arah zoom yang berlawanan
    • Anda harus berhati -hati di mana kursor berada ... Anda mungkin secara tidak sengaja memperbesar grafik ketika Anda bermaksud menggulir daftar grafik. Jadi saya biasanya meletakkan kursor di tepi kiri layar ketika saya ingin menggulir grafik.

  • Panning

    • Di laptop saya ini melakukan 2 jari pada gerakan gulir horizontal di touchpad
    • Menggunakan kotak hijau pada thumbnail di bawah grafik
    • Panning bekerja pada tingkat zoom apa pun
    • Gambar 'thumbnail' dari bagan lengkap diletakkan di bawah setiap bagan dengan kursor untuk meluncur di sepanjang thumbnail sehingga Anda dapat menavigasi di sekitar bagan saat Anda memperbesar/menggerakkan
    • Di bawah ini menunjukkan bagan 'CPU sibuk' ke T = 1.8-2.37 detik. Waktu relatif dan waktu mulai absolut tinggi di oval merah kiri. Waktu akhir disorot di oval merah sisi kanan. Posisi relatif pada thumbnail ditunjukkan oleh oval merah tengah.
    • bidikan layar panning .

  • Melayang pada entri legenda bagan menyoroti baris itu.

    • Di bawah ini adalah tangkapan layar di mana daya 'pkg' (paket) disorot
    • PKG Power disorot

  • Mengklik entri legenda diagram mengubah visibilitas baris itu.

  • mengklik dua kali entri legenda hanya membuat entri itu terlihat/disembunyikan

    • Di bawah ini adalah tangkapan layar di mana daya 'PKG' diklik dua kali sehingga hanya garis PKG yang terlihat.
    • Berikut adalah tangkapan layar di mana daya 'PKG' diklik dua kali sehingga hanya garis PKG yang terlihat.
    • Di atas menunjukkan sumbu y disesuaikan dengan min/maks dari variabel yang ditampilkan. Garis-garis 'tidak ditampilkan' adalah kelabu di legenda. Jika Anda melayang di atas garis 'tidak ditampilkan' di legenda itu akan ditarik (saat Anda melayang di item legenda). Anda bisa mendapatkan semua item untuk ditampilkan lagi dengan mengklik dua kali entri legenda yang 'tidak dikeringkan'. Ini akan menampilkan semua baris 'tidak ditampilkan' tetapi akan mematikan garis yang baru saja Anda klik ... jadi klik tunggal item yang baru saja Anda klik dua kali. Saya tahu itu terdengar membingungkan.

  • Jika entri legenda disembunyikan dan Anda melayang di atasnya, itu akan ditampilkan sampai Anda melayang keluar

Jenis Bagan:

  • Bagan 'CPU Busy': Bagan seperti kernelshark yang menunjukkan hunian CPU oleh PID/Thread. Lihat Referensi Kernelshark http://rostedt.homelinux.com/kernelshark/

    • Di bawah ini adalah tangkapan layar dari CPU Busy Chart. Bagan menunjukkan, untuk setiap CPU, proses/PID/TID berjalan pada titik waktu mana pun. Proses idle tidak ditarik. Untuk 'CPU 1' pada tangkapan layar, oval hijau ada di sekitar bagian 'sakelar konteks' dari bagan. Di atas setiap info sakelar konteks CPU, CPU sibuk menunjukkan peristiwa yang hadir dalam file yang sama dengan acara sakelar konteks. Oval merah pada baris CPU 1 menunjukkan bagian acara dari bagan.
    • bidikan layar dari bagan sibuk CPU
    • Bagan didasarkan pada acara sakelar konteks dan menunjukkan utas yang berjalan pada setiap CPU pada waktu tertentu
    • Acara Sakelar Konteks adalah Linux Scade: SCHART_SWITCH atau acara Windows ETW CSWITCH.
    • Jika ada lebih banyak peristiwa daripada sakelar konteks dalam file data maka semua peristiwa lain direpresentasikan sebagai tanda hubung vertikal di atas CPU.
    • Jika acara memiliki tumpukan panggilan maka tumpukan panggilan juga ditampilkan di balon popup

  • Bagan baris

    • Bagan garis mungkin lebih akurat disebut grafik langkah karena setiap peristiwa (sejauh ini) memiliki durasi dan 'durasi' ini diwakili oleh segmen horizontal dan bergabung dengan segmen vertikal.
    • Bagian vertikal dari bagan langkah dapat mengisi grafik jika garis grafik memiliki banyak variasi
    • Anda dapat memilih (di bilah nav kiri) untuk tidak menghubungkan segmen horizontal dari setiap baris ... sehingga bagan menjadi semacam grafik 'dasbor yang tersebar'. 'Dash horizonatal' adalah titik data aktual. Saat Anda beralih dari bagan langkah ke dasbor, bagan tidak digambar ulang sampai ada beberapa permintaan 'redraw' (seperti zoom/panci atau sorotan (dengan melayang di atas entri legenda)).
      • Di bawah ini adalah tangkapan layar dari status daya cpu_idle menggunakan bagan garis. Garis penghubung menghapus informasi dalam bagan.
      • Tangkapan layar cpu_idle status daya menggunakan grafik garis
      • Di bawah ini adalah tangkapan layar dari status daya CPU_IDLE menggunakan grafik yang tersebar-dash. Bagan sekarang menunjukkan dasbor horizontal untuk titik data (lebar dasbor adalah durasi acara). Sekarang kita dapat melihat lebih banyak informasi tetapi bagan ini juga menunjukkan kelemahan dengan logika bagan saya: banyak data berada pada nilai maksimal dan pada nilai min y dari grafik dan dikaburkan.
      • Tangkapan layar cpu_idle status Power menggunakan bagan dash yang tersebar

  • Bagan bertumpuk

    • Bagan yang ditumpuk dapat menyebabkan lebih banyak data yang dihasilkan daripada grafik garis. Misalnya, menggambar bagan garis saat utas tertentu hanya berjalan tergantung pada utas itu. Menggambar grafik yang ditumpuk untuk menjalankan utas berbeda: Acara sakelar konteks pada utas apa pun akan mengubah semua utas yang berjalan lainnya ... jadi jika Anda memiliki N CPU, Anda akan mendapatkan N-1 lebih banyak hal untuk menggambar per acara untuk grafik bertumpuk.

  • Flamegraphs. Untuk setiap acara perf yang memiliki CallStacks dan berada dalam file yang sama dengan acara SCHART_SWITCH/CSWITCH, Flamegraph dibuat.

    • Di bawah ini adalah tangkapan layar dari flamegraph default khas. Biasanya ketinggian default dari grafik Flamegraph tidak cukup untuk memasukkan teks ke dalam setiap level flamegraph. Tapi Anda masih mendapatkan info callstack 'hover'.
    • Tangkapan tangkapan layar dari flamegraph default khas .
    • Jika Anda mengklik lapisan bagan, itu memperluas lebih tinggi sehingga teks cocok. Jika Anda mengklik lapisan terendah maka itu mencakup semua data untuk interval 'bagan kepemilikan'.
    • Di bawah ini adalah tangkapan layar dari Flamegraph yang diperbesar (setelah mengklik salah satu lapisan api).
    • Tangkapan layar dari Flamegraph yang diperbesar .
    • Biasanya ketinggian default dari grafik Flamegraph tidak cukup untuk memasukkan teks ke dalam setiap level flamegraph. Tapi Anda masih mendapatkan info callstack 'hover'.
    • Warna flamegraph cocok dengan proses/pid/tid dalam legenda grafik cpu_busy ... jadi tidak secantik flamegraph tetapi sekarang warna 'nyala api' sebenarnya berarti sesuatu.
    • Bagan Flamegraph CPI (jam per instruksi) mewarnai proses/pid/tid oleh CPI untuk tumpukan itu.
      • Di bawah ini adalah sampel grafik CPI yang tidak diperbesar. Contoh kiri spin.x (dalam oranye ringan) memiliki CPI = 2,26 siklus/instruksi. 4 spin.x di sebelah kanan berwarna hijau muda memiliki CPI = 6.465.
      • Berikut adalah sampel bagan CPI yang tidak beres
      • Anda harus memiliki siklus, instruksi, dan callstacks cpu-clock (atau sched_switch)
      • Lebar CPI 'Api' didasarkan pada waktu CPU-jam.
      • Warnanya didasarkan pada CPI. Gradien merah hingga hijau hingga biru di kiri atas bagan menunjukkan pewarnaan.
      • Merah adalah CPI rendah (sangat banyak instruksi per jam ... Saya menganggapnya sebagai 'panas')
      • Biru adalah CPI tinggi (sangat sedikit instruksi per jam ... Saya menganggapnya sebagai 'dingin')
      • Di bawah ini adalah sampel grafik CPI yang diperbesar yang menunjukkan pewarnaan dan CPI. Utas 'spin.x' telah dipilih dalam legenda CPU_BUSY sehingga tidak muncul di Flamegraph.
      • Di bawah ini adalah sampel grafik CPI yang diperbesar.
    • Bagan Flamegraph GIG (Giga (miliar) per detik) mewarnai proses/pid/tid oleh gips untuk tumpukan itu.
      • Di bawah ini adalah sampel grafik GIPS (GIGA/miliar per detik) yang tidak diperbesar. Contoh kiri spin.x (berwarna hijau muda) memiliki gips = 1.13. 4 spin.x di sebelah kanan berwarna hijau biru memiliki gips = 0,377. Callstack di balon adalah untuk satu lonjakan callstacks di sebelah kiri balon.
      • Berikut adalah sampel grafik gips tanpa zoomed
      • Dalam bagan di atas, perhatikan bahwa tumpukan kiri (untuk spin.x) mendapatkan instruksi yang lebih tinggi/detik dari 4 instance paling kanan dari spin.x. Instance pertama dari spin.x ini berjalan dengan sendirinya (jadi mendapat banyak memori BW) dan benar 4 utas spin.x dijalankan secara paralel dan dapatkan gips yang lebih rendah (karena satu utas hanya dapat mengakses memori BW).
      • Anda harus memiliki instruksi dan callstacks cpu-clock (atau sched_switch)
      • Lebar gips 'api' didasarkan pada waktu cpu-jam.
      • Warnanya didasarkan pada gips. Gradien merah hingga hijau hingga biru di kiri atas bagan menunjukkan pewarnaan.
      • Merah adalah gip tinggi (jadi banyak instruksi per detik ... saya menganggapnya sebagai 'panas' melakukan banyak pekerjaan)
      • Biru adalah gip rendah (sangat sedikit instruksi per detik ... saya menganggapnya sebagai 'dingin')
      • Di bawah ini adalah sampel grafik gips zoomed yang menunjukkan pewarnaan dan gips. Saya mengklik 'perf 3186/3186' jadi nyala api ditunjukkan di bawah ini.
      • Di bawah ini adalah grafik Gips Zoomed Contoh
    • Jika Anda menyembunyikan suatu proses di legenda (klik entri Legend ... itu akan diabaikan) maka prosesnya tidak akan ditampilkan di Flamegraph.
    • Jika Anda benar menyeret mouse di Flamegraph, bagian Flamegraph akan diperbesar
    • mengklik zoom 'api' untuk hanya api itu
    • Menyeret mouse ke kiri di Flamegraph akan meluncur keluar
    • mengklik level yang lebih rendah dari flamegraph 'unzooms' ke semua data untuk level itu
    • Jika Anda mengklik level 'semua' level terendah dari Flamegraph, Anda akan memperbesar sepanjang jalan
    • Saat Anda mengklik level flamegraph, grafik diubah ukurannya sehingga setiap level cukup tinggi untuk menampilkan teks. Ini menyebabkan grafik mengubah ukuran. Untuk mencoba dan menambahkan kewarasan ke ukuran ini, saya memposisikan level terakhir dari grafik yang diubah ukuran ke bawah layar yang terlihat.
    • Jika Anda kembali ke legenda dan melayang di atas entri tersembunyi maka entri itu akan ditampilkan di Flamegraph sampai Anda melayang keluar
    • Jika Anda mengklik level atas 'nyala' maka bagian itu akan diperbesar.
    • Jika Anda memperbesar/keluar pada bagan 'induk' maka flamegraph akan digambar ulang untuk interval yang dipilih
    • Jika Anda menggerakkan/kanan pada bagan 'induk' maka flamegraph akan digambar ulang untuk interval yang dipilih
    • Secara default teks dari setiap level grafik api mungkin tidak cocok. Jika Anda mengklik Flamegraph maka ukurannya akan diperluas untuk mengaktifkan menggambar teks juga
    • Anda dapat memilih (di bilah Nav kiri) apakah akan mengelompokkan flamegraph dengan proses/pid/tid atau dengan proses/pid atau hanya dengan proses.
    • Baik 'di CPU', 'OFF CPU' dan 'Run Queue' Flamegraphs ditarik.
      • 'On CPU' adalah callstack untuk apa yang dilakukan utas saat berjalan di CPU ... jadi sampel callstacks atau perf cpu-clock callstacks menunjukkan apa yang dilakukan utas saat berjalan di CPU
      • Pertunjukan 'Off CPU', untuk utas yang tidak berjalan, berapa lama mereka menunggu dan callstack ketika mereka ditukar.
        • Di bawah ini adalah tangkapan layar dari di luar-CPU atau bagan waktu tunggu. Pertunjukan popup (di Flamegraph) bahwa 'wait.x' sedang menunggu di Nanosleep.
        • Tangkapan layar dari bagan wait_time
        • 'Status pertukaran' (dan pada ETW 'alasan') ditampilkan sebagai tingkat di atas proses. Biasanya sebagian besar utas akan tidur atau tidak berjalan tetapi ini membantu seseorang untuk menjawab pertanyaan: "Ketika utas saya tidak berjalan ... apa yang ditunggu -tunggu?".
        • Menampilkan 'status' untuk sakelar konteks memungkinkan Anda melihat:
        • Misalnya, apakah utas sedang menunggu tidur yang tidak diselesaikan (status == d di Linux ... biasanya io)
        • Tidur Interruptible (State = S ... sering kali tidur nanos atau futex)
      • 'Run Queue' menunjukkan utas yang ditukar dan dalam keadaan berlari atau runnable. Jadi bagan ini menunjukkan saturasi CPU jika ada utas dalam keadaan runnable tetapi tidak berjalan.
        • Di bawah ini adalah tangkapan layar dari grafik run_queue. Bagan ini menunjukkan jumlah waktu yang tidak dijalankan oleh utas karena tidak ada cukup CPU. Artinya, sudah siap untuk berjalan tetapi sesuatu yang lain menggunakan CPU. Setiap Flamegraph menunjukkan total yang dibahas dalam grafik. Dalam kasus grafik run_queue, ini menunjukkan ~ 159 msec pada waktu tunggu. Jadi, mengingat bahwa Spin.x memiliki waktu berjalan sekitar 20 detik dan waktu 'tunggu' 0,159 detik, itu tampaknya tidak terlalu buruk.
        • screenshot dari grafik run_queue

  • Saya tidak memiliki pustaka grafik berbasis kanvas untuk digunakan sehingga grafiknya agak kasar ... Saya tidak ingin menghabiskan terlalu banyak waktu untuk membuat grafik jika ada sesuatu yang lebih baik di luar sana. Bagan harus menggunakan kanvas HTML (bukan SVGS, D3.js dll) karena jumlah data.

Pengumpulan Data untuk Oppat

Mengumpulkan kinerja dan data daya sangat 'situasional'. Satu orang akan ingin menjalankan skrip, yang lain akan ingin memulai pengukuran dengan tombol, kemudian memulai video dan kemudian mengakhiri koleksi dengan menekan tombol. Saya memiliki skrip untuk Windows dan skrip untuk Linux yang menunjukkan:

  • Memulai pengumpulan data,
  • menjalankan beban kerja,
  • Hentikan pengumpulan data
  • Post-Process Data (Membuat file teks dari data biner perf/xperf/trace-CMD)
  • Menempatkan semua file data dalam Dir output
  • Membuat file file_list.json di output dir (yang memberi tahu oppat nama dan jenis file output)

Langkah -langkah untuk pengumpulan data menggunakan skrip:

  • Bangun utilitas spin.exe (spin.x) dan wait.exe (wait.x)
    • dari root oppat dir do:
    • di linux: ./mk_spin.sh
    • di windows : .mk_spin.bat (dari kotak CMD studio visual)
    • Binari akan dimasukkan ke dalam subdir ./bin
  • Mulailah dengan menjalankan skrip yang disediakan:
    • run_perf_x86_haswell.sh - untuk pengumpulan data Haswell CPU_DIAGRAM
      • Di Linux, ketik: sudo bash ./scripts/run_perf.sh
      • Secara default skrip menempatkan data di dir ../oppat_data/lnx/mem_bw7
    • run_perf.sh - Anda harus menginstal Trace -CMD dan Perf
      • Di Linux, ketik: sudo bash ./scripts/run_perf.sh
      • Secara default skrip menempatkan data di dir ../oppat_data/lnx/mem_bw4
    • run_xperf.bat - Anda harus menginstal Xperf.exe.
      • Di Windows, dari kotak CMD dengan hak istimewa admin, ketik : .scriptsrun_xperf.sh
      • Secara default skrip menempatkan data di dir .. oppat_data win mem_bw4
    • Edit skrip run jika Anda ingin mengubah default
    • Selain file data, skrip run membuat file file_list.json di Dir output. Oppat menggunakan file file_list.json untuk mengetahui nama file dan jenis file dalam DIR output.
  • 'Beban kerja' untuk skrip run adalah spin.x (atau spin.exe) yang melakukan tes bandwidth memori pada 1 CPU selama 4 detik dan kemudian pada semua CPU selama 4 detik lagi.
  • Program lain Wait.x/Wait.exe juga dimulai di latar belakang. Wait.cpp membaca info baterai untuk laptop saya. Ini berfungsi pada laptop dual boot windows 10/linux ubuntu saya. File SYSFS mungkin memiliki nama yang berbeda di Linux Anda dan hampir pasti berbeda di Android.
  • Di Linux, Anda mungkin hanya bisa menghasilkan file prf_trace.data dan prf_trace.txt menggunakan sintaks yang sama seperti di run_perf.sh tapi saya belum mencoba ini.
  • Jika Anda berjalan di laptop dan ingin mendapatkan daya baterai, ingatlah untuk melepaskan kabel daya sebelum Anda menjalankan skrip.

Dukungan Data PCM

  • Oppat dapat membaca dan memetakan file PCM .csv.
  • Di bawah ini adalah snapshot dari daftar bagan yang dibuat.
    • Tangkapan layar Navbar dengan grafik PCM
  • Sayangnya Anda harus melakukan patch ke PCM untuk membuat file dengan cap waktu absolut untuk diproses.
    • Ini karena file CSV PCM tidak memiliki cap waktu yang dapat saya gunakan untuk berkorelasi dengan sumber data lainnya.
  • Saya telah menambahkan tambalan di sini PCM Patch

Membangun Oppat

  • Di Linux, ketik make In The Oppat Root Dir
    • Jika semuanya berfungsi harus ada file bin/oppat.x
  • Di windows, Anda perlu:
    • Instal versi Windows dari GNU Make. Lihat http://gnuwin32.sourceForge.net/packages/make.htm atau, hanya untuk biner minimum yang diperlukan, gunakan http://gnuwin32.sourceForge.net/downlinks/make.php
    • Letakkan biner 'make' baru ini di jalan setapak
    • Anda memerlukan Visual Studio 2015 atau 2017 C/C ++ Compiler saat ini (saya menggunakan VS 2015 Professional dan Compiler Komunitas VS 2017)
    • Mulai kotak prompt CMD asli Studio Visual X64
    • Ketik make di Oppat Root Dir
    • Jika semuanya berfungsi harus ada file bin oppat.exe
  • Jika Anda mengubah kode sumber, Anda mungkin perlu membangun kembali file ketergantungan termasuk
    • Anda harus menginstal Perl
    • di Linux, di root oppat do: ./mk_depends.sh . Ini akan membuat file dependensi dependen_lnx.mk.
    • on Windows, in the OPPAT root dir do: .mk_depends.bat . This will create a depends_win.mk dependency file.
  • If you are going to run the sample run_perf.sh or run_xperf.bat scripts, then you need to build the spin and wait utilities:
    • On Linux: ./mk_spin.sh
    • On Windows: .mk_spin.bat

Running OPPAT

  • Run the data collection steps above
    • now you have data files in a dir (if you ran the default run_* scripts:
      • on Windows ..oppat_datawinmem_bw4
      • on Linux ../oppat_data/lnx/mem_bw4
    • You need to add the created files to the input_filesinput_data_files.json file:
  • Starting OPPAT reads all the data files and starts the web server
  • on Windows to generate the haswell cpu_diagram (assuming your data dir is ..oppat_datalnxmem_bw7) 
   binoppat.exe -r ..oppat_datalnxmem_bw7 --cpu_diagram webhaswell_block_diagram.svg > tmp.txt
  • on Windows (assuming your data dir is ..oppat_datawinmem_bw4) 
   binoppat.exe -r ..oppat_datawinmem_bw4 > tmp.txt
  • on Linux (assuming your data dir is ../oppat_data/lnx/mem_bw4) 
   bin/oppat.exe -r ../oppat_data/lnx/mem_bw4 > tmp.txt

  • Now connect your browser to localhost:8081

  • You can create a standalone HTML file with the '--web_file some_file.html' option. Misalnya: 

   bin/oppat.exe -r ../oppat_data/lnx/mem_bw4 --web_file tst2.html > tmp.txt
  • Then you can load the file into the browser with the URL address: file:///C:/some_path/oppat/tst2.html

Derived Events

'Derived events' are new events created from 1 or more events in a data file.

  • Say you want to use the ETW Win32k InputDeviceRead events to track when the user is typing or moving the mouse.
    • ETW has 2 events:
      • Microsoft-Windows-Win32k/InputDeviceRead/win:Start
      • Microsoft-Windows-Win32k/InputDeviceRead/win:Stop
    • So with the 2 above events we know when the system started reading input and we know when it stopped reading input
    • But OPPAT plots just 1 event per chart (usually... the cpu_busy chart is different)
    • We need a new event that marks the end of the InputDeviceRead and the duration of the event
  • The derived event needs:
    • a new event name (in chart.json... see for example the InputDeviceRead event)
    • a LUA file and routine in src_lua subdir
    • 1 or more 'used events' from which the new event is derived
      • the derived events have to be in the same file
      • For the InputDeviceRead example, the 2 Win32k InputDeviceRead Start/Stop events above are used.
  • The 'used events' are passed to the LUA file/routine (along with the column headers for the 'used events') as the events are encountered in the input trace file
    • In the InputDeviceRead lua script:
      • the script records the timestamp and process/pid/tid of a 'start' event
      • when the script gets a matching 'Stop' event (matching on process/pid/tid), the script computes a duration for the new event and passes it back to OPPAT
  • A 'trigger event' is defined in chart.json and if the current event is the 'trigger event' then (after calling the lua script) the new event is emitted with the new data field(s) from the lua script.
  • An alternate to the 'trigger event' method is to have the lua script indicate whether or not it is time to write the new event. For instance, the scr_lua/prf_CPI.lua script writes a '1' to a variable named ' EMIT ' to indicate that the new CPI event should be written.
  • The new event will have:
    • the name (from the chart.json evt_name field)
    • The data from the trigger event (except the event name and the new fields (appended)
  • I have tested this on ETW data and for perf/trace-cmd data

Using the browser GUI Interface

TBD

Defining events and charts in charts.json

TBD

Rules for input_data_files.json

  • The file 'input_files/input_data_files.json' can be used to maintain a big list of all the data directories you have created.
  • You can then select the directory by just specifying the file_tag like:
    • bin/oppat.x -u lnx_mem_bw4 > tmp.txt # assuming there is a file_tag 'lnx_mem_bw4' in the json file.
  • The big json file requires you to copy the part of the data dir's file_list.json into input_data_files.json
    • in the file_list.json file you will see lines like: 
{ "cur_dir" : " %root_dir%/oppat_data/win/mem_bw4 " },
{ "cur_tag" : " win_mem_bw4 " },
{ "txt_file" : " etw_trace.txt " , "tag" : " %cur_tag% " , "type" : " ETW " },
{ "txt_file" : " etw_energy2.txt " , "wait_file" : " wait.txt " , "tag" : " %cur_tag% " , "type" : " LUA " }
  • don't copy the lines like below from the file_list.json file: 
{ "file_list" :[ 
  ]}
  • paste the copied lines into input_data_files.json. Pay attention to where you paste the lines. If you are pasting the lines at the top of input_data_files.json (after the {"root_dir":"/data/ppat/"}, then you need add a ',' after the last pasted line or else JSON will complain.
  • for Windows data files add an entry like below to the input_filesinput_data_files.json file:
    • yes, use forward slashes: 
{ "root_dir" : " /data/ppat/ " },
{ "cur_dir" : " %root_dir%/oppat_data/win/mem_bw4 " },
{ "cur_tag" : " win_mem_bw4 " },
{ "txt_file" : " etw_trace.txt " , "tag" : " %cur_tag% " , "type" : " ETW " },
{ "txt_file" : " etw_energy2.txt " , "wait_file" : " wait.txt " , "tag" : " %cur_tag% " , "type" : " LUA " }
  • for Linux data files add an entry like below to the input_filesinput_data_files.json file: 
{ "root_dir" : " /data/ppat/ " },
{ "cur_dir" : " %root_dir%/oppat_data/lnx/mem_bw4 " },
{ "cur_tag" : " lnx_mem_bw4 " },
{ "bin_file" : " prf_energy.txt " , "txt_file" : " prf_energy2.txt " , "wait_file" : " wait.txt " , "tag" : " %cur_tag% " , "type" : " LUA " },
{ "bin_file" : " prf_trace.data " , "txt_file" : " prf_trace.txt " , "tag" : " %cur_tag% " , "type" : " PERF " },
{ "bin_file" : " tc_trace.dat " ,  "txt_file" : " tc_trace.txt " , "tag" : " %cur_tag% " , "type" : " TRACE_CMD " },
  • Unfortunately you have to pay attention to proper JSON syntax (such as trailing ','s)
  • Here is an explanation of the fields:
    • The 'root_dir' field only needs to entered once in the json file.
      • It can be overridden on the oppat cmd line line with the -r root_dir_path option
      • If you use the -r root_dir_path option it is as if you had set "root_dir":"root_dir_path" in the json file
      • the 'root_dir' field has to be on a line by itself.
    • The cur_dir field applies to all the files after the cur_dir line (until the next cur_dir line)
      • the '%root_dir% string in the cur_dir field is replaced with the current value of 'root_dir'.
      • the 'cur_dir' field has to be on a line by itself.
    • the 'cur_tag' field is a text string used to group the files together. The cur_tag field will be used to replace the 'tag' field on each subsequent line.
      • the 'cur_tag' field has to be on a line by itself.
    • For now there are four types of data files indicated by the 'type' field:
      • type:PERF These are Linux perf files. OPPAT currently requires both the binary data file (the bin_file field) created by the perf record cmd and the perf script text file (the txt_file field).
      • type:TRACE_CMD These are Linux trace-cmd files. OPPAT currently requires both the binary dat file (the bin_file field) created by the trace-cmd record cmd and the trace-cmd report text file (the txt_file field).
      • type:ETW These are Windows ETW xperf data files. OPPAT currently requires only the text file (I can't read the binary file). The txt_file is created with xperf ... -a dumper command.
      • type:LUA These files are all text files which will be read by the src_lua/test_01.lua script and converted to OPPAT data.
        • the 'prf_energy.txt' file is perf stat output with Intel RAPL energy data and memory bandwidth data.
        • the 'prf_energy2.txt' file is created by the wait utility and contains battery usage data in the 'perf stat' format.
        • the 'wait.txt' file is created by the wait utility and shows the timestamp when the wait utility began
          • Unfortunately 'perf stat' doesn't report a high resolution timestamp for the 'perf stat' start time

Batasan

  • The data is not reduced on the back-end so every event is sent to the browser... this can be a ton of data and overwhelm the browsers memory
    • I probably should have some data reduction logic but I wanted to get feedback first
    • You can clip the files to a time range: oppat.exe -b abs_beg_time -e abs_beg_time to reduce the amout of data
      • This is a sort of crude mechanism right now. I just check the timestamp of the sample and discard it if the timestamp is outside the interval. If the sample has a duration it might actually have data for the selected interval...
    • There are many cases where you want to see each event as opposed to averages of events.
    • On my laptop (with 4 CPUs), running for 10 seconds of data collection runs fine.
    • Servers with lots of CPUs or running for a long time will probably blow up OPPAT currently.
    • The stacked chart can cause lots of data to be sent due to how it each event on one line is now stacked on every other line.
  • Limited mechanism for a chart that needs more than 1 event on a chart...
    • say for computing CPI (cycles per instruction).
    • Or where you have one event that marks the 'start' of some action and another event that marks the 'end' of the action
    • There is a 'derived events' logic that lets you create a new event from 1 or more other events
    • See the derived event section
  • The user has to supply or install the data collection software:
    • on Windows xperf
      • See https://docs.microsoft.com/en-us/windows-hardware/get-started/adk-install
      • You don't need to install the whole ADK... the 'select the parts you want to install' will let you select just the performance tools
    • on Linux perf and/or trace-cmd
      • For perf, try: 
sudo apt-get install linux-tools-common linux-tools-generic linux-tools- ` uname -r `
  • For trace-cmd, see https://github.com/rostedt/trace-cmd
    • You can do (AFAIK) everything in 'perf' as you can in 'trace-cmd' but I have found trace-cmd has little overhead... perhaps because trace-cmd only supports tracepoints whereas perf supports tracepoints, sampling, callstacks and more.
  • Currently for perf and trace-cmd data, you have to give OPPAT both the binary data file and the post-processed text file.
    • Having some of the data come from the binary file speeds things up and is more reliable.
    • But I don't want to the symbol handling and I can't really do the post-processing of the binary data. Near as I can tell you have to be part of the kernel to do the post processing.
  • OPPAT requires certain clocks and a certain syntax of 'convert to text' for perf and trace-cmd data.
    • OPPAT requires clock_monotonic so that different file timestamps can be correlated.
    • When converting the binary data to text (trace-cmd report or 'perf script') OPPAT needs the timestamp to be in nanoseconds.
    • see scriptsrun_xperf.bat and scriptsrun_perf.sh for the required syntax
  • given that there might be so many files to read (for example, run_perf.sh generates 7 input files), it is kind of a pain to add these files to the json file input_filesinput_data_files.json.
    • the run_xperf.bat and run_perf.sh generate a file_list.json in the output directory.
  • perf has so, so many options... I'm sure it is easy to generate some data which will break OPPAT
    • The most obvious way to break OPPAT is to generate too much data (causing browser to run out of memory). I'll probably handle this case better later but for this release (v0.1.0), I just try to not generate too much data.
    • For perf I've tested:
      • sampling hardware events (like cycles, instructions, ref-cycles) and callstacks for same
      • software events (cpu-clock) and callstacks for same
      • tracepoints (sched_switch and a bunch of others) with/without callstacks
  • Zooming Using touchpad scroll on Firefox seems to not work as well it works on Chrome
Memperluas
Informasi Tambahan
Aplikasi Terkait
Direkomendasikan untuk Anda
Informasi Terkait Semua