Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Halaman ini diterjemahkan oleh Cloud Translation API.

Menggunakan ftrace

ftrace adalah alat debugging untuk memahami apa yang terjadi di dalam kernel Linux. Bagian berikut merinci fungsionalitas dasar ftrace, penggunaan ftrace dengan atrace (yang menangkap peristiwa kernel), dan ftrace dinamis.

Untuk detail tentang fungsionalitas ftrace lanjutan yang tidak tersedia dari systrace, lihat dokumentasi ftrace di <kernel tree>/Documentation/trace/ftrace.txt .

Menangkap peristiwa kernel dengan atrace

atrace ( frameworks/native/cmds/atrace ) menggunakan ftrace untuk menangkap peristiwa kernel. Pada gilirannya, systrace.py (atau run_systrace.py di versi Catapult yang lebih baru) menggunakan adb untuk menjalankan atrace di perangkat. atrace melakukan hal berikut:

Menyiapkan pelacakan mode pengguna dengan menyetel properti ( debug.atrace.tags.enableflags ).
Mengaktifkan fungsionalitas ftrace yang diinginkan dengan menulis ke node ftrace sysfs yang sesuai. Namun, karena ftrace mendukung lebih banyak fitur, Anda dapat mengatur sendiri beberapa node sysfs kemudian menggunakan atrace.

Dengan pengecualian pelacakan waktu booting, andalkan penggunaan atrace untuk menyetel properti ke nilai yang sesuai. Properti ini adalah bitmask dan tidak ada cara yang baik untuk menentukan nilai yang benar selain melihat header yang sesuai (yang dapat berubah di antara rilis Android).

Mengaktifkan acara ftrace

Node sysfs ftrace berada di /sys/kernel/tracing dan melacak peristiwa dibagi ke dalam kategori di /sys/kernel/tracing/events .

Untuk mengaktifkan acara per kategori, gunakan:

echo 1 > /sys/kernel/tracing/events/irq/enable

Untuk mengaktifkan acara berdasarkan per acara, gunakan:

echo 1 > /sys/kernel/tracing/events/sched/sched_wakeup/enable

Jika event tambahan telah diaktifkan dengan menulis ke sysfs node, event tersebut tidak akan direset oleh atrace. Pola umum untuk pengaktifan perangkat Qualcomm adalah mengaktifkan kgsl (GPU) dan mdss (pipa tampilan), lalu menggunakan atrace atau systrace :

adb shell "echo 1 > /sys/kernel/tracing/events/mdss/enable"
adb shell "echo 1 > /sys/kernel/tracing/events/kgsl/enable"
./systrace.py sched freq idle am wm gfx view binder_driver irq workq ss sync -t 10 -b 96000 -o full_trace.html

Anda juga dapat menggunakan ftrace tanpa atrace atau systrace, yang berguna saat Anda menginginkan pelacakan hanya kernel (atau jika Anda telah meluangkan waktu untuk menulis properti penelusuran mode pengguna dengan tangan). Untuk menjalankan hanya ftrace:

Atur ukuran buffer ke nilai yang cukup besar untuk jejak Anda:
```
echo 96000 > /sys/kernel/tracing/buffer_size_kb
```

Aktifkan pelacakan:

echo 1 > /sys/kernel/tracing/tracing_on

Jalankan pengujian Anda, lalu nonaktifkan pelacakan:
```
echo 0 > /sys/kernel/tracing/tracing_on
```

Buang jejaknya:

cat /sys/kernel/tracing/trace > /data/local/tmp/trace_output

trace_output memberikan jejak dalam bentuk teks. Untuk memvisualisasikannya menggunakan Catapult, dapatkan repositori Catapult dari GitHub dan jalankan trace2html:

catapult/tracing/bin/trace2html ~/path/to/trace_file

Secara default, ini menulis trace_file.html di direktori yang sama.

Peristiwa yang berhubungan

Seringkali berguna untuk melihat visualisasi Catapult dan log ftrace secara bersamaan; misalnya, beberapa acara ftrace (terutama yang khusus vendor) tidak divisualisasikan oleh Catapult. Namun, stempel waktu Catapult relatif terhadap peristiwa pertama dalam jejak atau stempel waktu tertentu yang dibuang oleh atrace, sedangkan stempel waktu ftrace mentah didasarkan pada sumber jam absolut tertentu di kernel Linux.

Untuk menemukan acara ftrace tertentu dari acara Catapult:

Buka log ftrace mentah. Jejak dalam versi terbaru systrace dikompresi secara default:
- Jika Anda menangkap systrace Anda dengan --no-compress , ini ada di file html di bagian yang dimulai dengan BEGIN TRACE.
- Jika tidak, jalankan html2trace dari pohon Catapult ( tracing/bin/html2trace ) untuk membuka kompresi jejak.
Temukan stempel waktu relatif dalam visualisasi Catapult.
Temukan baris di awal jejak yang berisi tracing_mark_sync . Seharusnya terlihat seperti ini:
```
<5134>-5134  (-----) [003] ...1    68.104349: tracing_mark_write: trace_event_clock_sync: parent_ts=68.104286
```
Jika baris ini tidak ada (atau jika Anda menggunakan ftrace tanpa atrace), maka pengaturan waktu akan relatif dari peristiwa pertama di log ftrace.
1. Tambahkan stempel waktu relatif (dalam milidetik) ke nilai dalam parent_ts (dalam detik).
2. Cari stempel waktu baru.

Langkah-langkah ini harus menempatkan Anda di (atau setidaknya sangat dekat dengan) acara tersebut.

Menggunakan ftrace dinamis

Ketika systrace dan ftrace standar tidak mencukupi, ada satu jalan terakhir yang tersedia: dynamic ftrace . Ftrace dinamis melibatkan penulisan ulang kode kernel setelah boot, dan akibatnya kode tersebut tidak tersedia di kernel produksi karena alasan keamanan. Namun, setiap bug kinerja yang sulit pada tahun 2015 dan 2016 pada akhirnya disebabkan oleh akar menggunakan ftrace dinamis. Ini sangat kuat untuk men-debug tidur yang tidak pernah terputus karena Anda bisa mendapatkan jejak tumpukan di kernel setiap kali Anda menekan fungsi yang memicu tidur yang tidak pernah terputus. Anda juga dapat men-debug bagian dengan interupsi dan preemption dinonaktifkan, yang bisa sangat berguna untuk membuktikan masalah.

Untuk mengaktifkan ftrace dinamis, edit defconfig kernel Anda:

Hapus CONFIG_STRICT_MEMORY_RWX (jika ada). Jika Anda menggunakan 3.18 atau lebih baru dan arm64, itu tidak ada.
Tambahkan berikut ini: CONFIG_DYNAMIC_FTRACE=y, CONFIG_FUNCTION_TRACER=y, CONFIG_IRQSOFF_TRACER=y, CONFIG_FUNCTION_PROFILER=y, dan CONFIG_PREEMPT_TRACER=y
Bangun kembali dan boot kernel baru.
Jalankan yang berikut ini untuk memeriksa pelacak yang tersedia:
```
cat /sys/kernel/tracing/available_tracers
```
Konfirmasikan function pengembalian perintah , irqsoff , preemptoff , dan preemptirqsoff .

Jalankan yang berikut ini untuk memastikan ftrace dinamis berfungsi:

cat /sys/kernel/tracing/available_filter_functions | grep <a function you care about>

Setelah menyelesaikan langkah-langkah ini, Anda memiliki ftrace dinamis, profiler fungsi, profiler irqsoff, dan profiler preemptoff yang tersedia. Kami sangat menyarankan untuk membaca dokumentasi ftrace tentang topik ini sebelum menggunakannya karena sangat kuat tetapi kompleks. irqsoff dan preemptoff terutama berguna untuk mengonfirmasi bahwa driver mungkin membiarkan interupsi atau preemptoff dimatikan terlalu lama.

Profiler fungsi adalah opsi terbaik untuk masalah kinerja dan sering digunakan untuk mencari tahu di mana suatu fungsi dipanggil.

Tampilkan Masalah: Foto HDR + jendela bidik berputar

Dalam masalah ini, menggunakan Pixel XL untuk mengambil foto HDR+ kemudian segera memutar jendela bidik yang menyebabkan jank setiap saat. Kami menggunakan profiler fungsi untuk men-debug masalah dalam waktu kurang dari satu jam. Untuk mengikuti contoh, unduh file zip traces (yang juga menyertakan trace lain yang dirujuk di bagian ini), unzip file, dan buka file trace_30898724.html di browser Anda.

Jejak menunjukkan beberapa utas dalam proses server kamera yang diblokir dalam mode tidur tanpa gangguan di ion_client_destroy . Itu adalah fungsi yang mahal, tetapi harus jarang dipanggil karena klien ion harus mencakup banyak alokasi. Awalnya, kesalahan jatuh pada kode Hexagon di Halide, yang memang salah satu penyebabnya (itu menciptakan klien baru untuk setiap alokasi ion dan menghancurkan klien itu ketika alokasi dibebaskan, yang terlalu mahal). Pindah ke klien ion tunggal untuk semua alokasi Hexagon memperbaiki situasi, tetapi jank tidak diperbaiki.

Pada titik ini kita perlu mengetahui siapa yang memanggil ion_client_destroy , jadi saatnya menggunakan fungsi profiler:

Karena fungsi terkadang diganti namanya oleh kompiler, konfirmasikan ion_client_destroy ada dengan menggunakan:
```
cat /sys/kernel/tracing/available_filter_functions | grep ion_client_destroy
```
Setelah mengonfirmasi itu ada, gunakan itu sebagai filter ftrace: l10n
```
echo ion_client_destroy > /sys/kernel/tracing/set_ftrace_filter
```

Aktifkan profiler fungsi:

echo function > /sys/kernel/tracing/current_tracer

Aktifkan pelacakan tumpukan setiap kali fungsi filter dipanggil:
```
echo func_stack_trace > /sys/kernel/tracing/trace_options
```

Tingkatkan ukuran buffer:

echo 64000 > /sys/kernel/tracing/buffer_size_kb

Aktifkan pelacakan:
```
echo 1 > /sys/kernel/tracing/trace_on
```

Jalankan tes dan dapatkan jejaknya:

cat /sys/kernel/tracing/trace > /data/local/tmp/trace

Lihat jejak untuk melihat banyak dan banyak jejak tumpukan:

    cameraserver-643   [003] ...1    94.192991: ion_client_destroy <-ion_release
    cameraserver-643   [003] ...1    94.192997: <stack trace>
 => ftrace_ops_no_ops
 => ftrace_graph_call
 => ion_client_destroy
 => ion_release
 => __fput
 => ____fput
 => task_work_run
 => do_notify_resume
 => work_pending

Berdasarkan pemeriksaan driver ion, kita dapat melihat bahwa ion_client_destroy sedang di-spam oleh fungsi userspace yang menutup fd ke /dev/ion , bukan driver kernel acak. Dengan menelusuri basis kode Android untuk \"/dev/ion\" , kami menemukan beberapa driver vendor melakukan hal yang sama seperti driver Hexagon dan membuka/menutup /dev/ion (membuat dan menghancurkan klien ion baru) setiap kali mereka membutuhkan alokasi ion baru. Mengubahnya untuk menggunakan klien ion tunggal selama proses seumur hidup memperbaiki bug.

Jika data dari profiler fungsi tidak cukup spesifik, Anda dapat menggabungkan titik jejak ftrace dengan profiler fungsi. acara ftrace dapat diaktifkan dengan cara yang persis sama seperti biasanya, dan mereka akan disisipkan dengan jejak Anda. Ini bagus jika ada waktu tidur lama yang tidak pernah terputus dalam fungsi tertentu yang ingin Anda debug: atur filter ftrace ke fungsi yang Anda inginkan, aktifkan tracepoints, ambil jejak. Anda dapat mengurai jejak yang dihasilkan dengan trace2html , menemukan acara yang Anda inginkan, lalu mendapatkan jejak tumpukan terdekat di jejak mentah.

Menggunakan lockstat

Kadang-kadang, ftrace tidak cukup dan Anda benar-benar perlu men-debug apa yang tampaknya merupakan pertentangan kunci kernel. Ada satu lagi opsi kernel yang patut dicoba: CONFIG_LOCK_STAT . Ini adalah upaya terakhir karena sangat sulit untuk bekerja di perangkat Android karena ukuran kernel membengkak melebihi apa yang dapat ditangani oleh sebagian besar perangkat.

Namun, lockstat menggunakan infrastruktur penguncian debug, yang berguna untuk banyak aplikasi lain. Semua orang yang bekerja di perangkat memunculkan harus mencari cara agar opsi itu berfungsi di setiap perangkat karena akan ada saatnya ketika Anda berpikir "Kalau saja saya bisa mengaktifkan LOCK_STAT , saya bisa mengonfirmasi atau membantah ini sebagai masalah dalam lima menit, bukan Lima hari."

Tampilkan Masalah: Berhenti di SCHED_FIFO saat inti pada beban maksimal dengan non-SCHED_FIFO

Dalam masalah ini, utas SCHED_FIFO terhenti ketika semua inti berada pada beban maksimum dengan utas non-SCHED_FIFO. Kami memiliki jejak yang menunjukkan pertentangan kunci yang signifikan pada fd di aplikasi VR, tetapi kami tidak dapat dengan mudah mengidentifikasi fd yang digunakan. Untuk mengikuti contoh, unduh file zip traces (yang juga menyertakan trace lain yang dirujuk di bagian ini), unzip file, dan buka file trace_30905547.html di browser Anda.

Kami berhipotesis bahwa ftrace itu sendiri adalah sumber pertengkaran kunci, ketika utas prioritas rendah akan mulai menulis ke pipa ftrace dan kemudian didahului sebelum dapat melepaskan kunci. Ini adalah skenario terburuk yang diperburuk oleh campuran penulisan utas dengan prioritas sangat rendah ke penanda ftrace bersama dengan beberapa utas dengan prioritas lebih tinggi yang berputar pada CPU untuk mensimulasikan perangkat yang terisi penuh.

Karena kami tidak dapat menggunakan ftrace untuk men-debug, kami membuat LOCK_STAT berfungsi lalu mematikan semua penelusuran lainnya dari aplikasi. Hasil penelitian menunjukkan lock contention sebenarnya dari ftrace karena tidak ada contention yang muncul di lock trace saat ftrace tidak berjalan.

Jika Anda dapat mem-boot kernel dengan opsi konfigurasi, pelacakan kunci mirip dengan ftrace:

Aktifkan pelacakan:
```
echo 1 > /proc/sys/kernel/lock_stat
```
Jalankan tes Anda.
Nonaktifkan pelacakan:
```
echo 0 > /proc/sys/kernel/lock_stat
```

Buang jejak Anda:

cat /proc/lock_stat > /data/local/tmp/lock_stat

Untuk bantuan dalam menginterpretasikan output yang dihasilkan, lihat dokumentasi lockstat di <kernel>/Documentation/locking/lockstat.txt .

Menggunakan titik jejak vendor

Gunakan titik jejak hulu terlebih dahulu, tetapi terkadang Anda perlu menggunakan titik jejak vendor:

  { "gfx",        "Graphics",         ATRACE_TAG_GRAPHICS, {
        { OPT,      "events/mdss/enable" },
        { OPT,      "events/sde/enable" },
        { OPT,      "events/mali_systrace/enable" },
    } },

Tracepoints dapat diperluas oleh layanan HAL yang memungkinkan Anda untuk menambahkan titik/kategori pelacakan khusus perangkat. Tracepoints terintegrasi dengan perfetto, atrace/systrace, dan aplikasi pelacakan sistem di perangkat.

API untuk mengimplementasikan tracepoint/kategori adalah:

listCategories() menghasilkan (vec<TracingCategory> kategori);
enableCategories(vec<string> kategori) menghasilkan (Status status);
disableAllCategories() menghasilkan (Status status);

Untuk informasi lebih lanjut, lihat definisi HAL dan implementasi default di AOSP :