ftrace'i kullanma

ftrace, Linux çekirdeğinin içinde neler olup bittiğini anlamak için kullanılan bir hata ayıklama aracıdır. Aşağıdaki bölümlerde temel ftrace işlevselliği, atrace ile ftrace kullanımı (çekirdek olaylarını yakalayan) ve dinamik ftrace ayrıntıları verilmektedir.

Systrace'te bulunmayan gelişmiş ftrace işlevselliğine ilişkin ayrıntılar için <kernel tree>/Documentation/trace/ftrace.txt adresindeki ftrace belgelerine bakın.

Atrace ile çekirdek olaylarını yakalama

atrace ( frameworks/native/cmds/atrace ), çekirdek olaylarını yakalamak için ftrace'i kullanır. Buna karşılık, systrace.py (veya Catapult'un sonraki sürümlerinde run_systrace.py), cihazda atrace'i çalıştırmak için adb'yi kullanır. atrace şunları yapar:

• Bir özelliği ( debug.atrace.tags.enableflags ) ayarlayarak kullanıcı modu izlemeyi ayarlar.
• Uygun ftrace sysfs düğümlerine yazarak istenen ftrace işlevselliğini etkinleştirir. Ancak ftrace daha fazla özelliği desteklediğinden, bazı sysfs düğümlerini kendiniz ayarlayabilir ve ardından atrace'i kullanabilirsiniz.

Önyükleme zamanı izleme dışında, özelliği uygun değere ayarlamak için atrace kullanımına güvenin. Özellik bir bit maskesidir ve doğru değerleri belirlemenin uygun başlığa bakmaktan başka iyi bir yolu yoktur (bu, Android sürümleri arasında değişebilir).

Ftrace olaylarını etkinleştirme

ftrace sysfs düğümleri /sys/kernel/tracing konumundadır ve trace olayları /sys/kernel/tracing/events konumunda kategorilere bölünmüştür.

Olayları kategori bazında etkinleştirmek için şunu kullanın:

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

Olayları olay bazında etkinleştirmek için şunu kullanın:

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

Eğer ekstra olaylar sysfs düğümlerine yazılarak etkinleştirildiyse, bunlar atrace tarafından sıfırlanmayacaktır . Qualcomm cihazının getirilmesi için yaygın bir model, kgsl (GPU) ve mdss (görüntü hattı) izleme noktalarını etkinleştirmek ve ardından atrace veya systrace kullanmaktır:

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

ftrace'i atrace veya systrace olmadan da kullanabilirsiniz; bu, yalnızca çekirdek izlemeleri istediğinizde (veya kullanıcı modu izleme özelliğini elle yazmaya zaman ayırdıysanız) kullanışlıdır. Sadece ftrace'i çalıştırmak için:

1. Arabellek boyutunu izlemeniz için yeterince büyük bir değere ayarlayın:

   echo 96000 > /sys/kernel/tracing/buffer_size_kb
   

2. İzlemeyi etkinleştir:

   echo 1 > /sys/kernel/tracing/tracing_on
   

3. Testinizi çalıştırın ve izlemeyi devre dışı bırakın:

   echo 0 > /sys/kernel/tracing/tracing_on
   

4. İzlemeyi boşalt:

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

Trace_output, izi metin biçiminde verir. Catapult'u kullanarak görselleştirmek için GitHub'dan Catapult deposunu alın ve trace2html'yi çalıştırın:

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

Varsayılan olarak bu, trace_file.html dosyasını aynı dizine yazar.

Olayları ilişkilendirmek

Catapult görselleştirmesine ve ftrace günlüğüne aynı anda bakmak genellikle faydalıdır; örneğin bazı ftrace olayları (özellikle satıcıya özel olanlar) Catapult tarafından görselleştirilmez. Bununla birlikte, Catapult'un zaman damgaları ya izdeki ilk olaya ya da atrace tarafından atılan belirli bir zaman damgasına göredir; ham ftrace zaman damgaları ise Linux çekirdeğindeki belirli bir mutlak saat kaynağına dayanır.

Bir Catapult olayından belirli bir ftrace olayını bulmak için:

1. Ham ftrace günlüğünü açın. Systrace'in son sürümlerindeki izler varsayılan olarak sıkıştırılmıştır:
   • Systrace'inizi --no-compress ile yakaladıysanız, bu, BEGIN TRACE ile başlayan bölümdeki html dosyasındadır.
   • Değilse, izi açmak için Catapult ağacından ( tracing/bin/html2trace ) html2trace'i çalıştırın.
2. Mancınık görselleştirmesinde ilgili zaman damgasını bulun.
3. İzlemenin başında tracing_mark_sync içeren bir satır bulun. Şunun gibi görünmeli:

   <5134>-5134  (-----) [003] ...1    68.104349: tracing_mark_write: trace_event_clock_sync: parent_ts=68.104286
   

   
   Bu satır yoksa (veya ftrace'i atrace olmadan kullandıysanız), zamanlamalar ftrace günlüğündeki ilk olaya göre olacaktır.
   1. Göreli zaman damgasını (milisaniye cinsinden) parent_ts (saniye cinsinden) değerine ekleyin.
   2. Yeni zaman damgasını arayın.

Bu adımlar sizi etkinliğe (veya en azından çok yaklaştıracak) yönlendirmelidir.

Dinamik ftrace'i kullanma

Systrace ve standart ftrace yetersiz kaldığında son bir çare vardır: dinamik ftrace . Dinamik ftrace, önyüklemeden sonra çekirdek kodunun yeniden yazılmasını içerir ve sonuç olarak güvenlik nedeniyle üretim çekirdeklerinde kullanılamaz. Bununla birlikte, 2015 ve 2016'daki her bir zorlu performans hatası, sonuçta dinamik ftrace kullanılarak ortaya çıkan temel nedenlerden kaynaklanıyordu. Kesintisiz uykularda hata ayıklamak için özellikle güçlüdür çünkü kesintisiz uykuyu tetikleyen işleve her bastığınızda çekirdekte bir yığın izleme elde edebilirsiniz. Ayrıca, kesintilerin ve önlemelerin devre dışı bırakıldığı bölümlerde hata ayıklayabilirsiniz; bu, sorunları kanıtlamak için çok yararlı olabilir.

Dinamik ftrace'i açmak için çekirdeğinizin defconfig'ini düzenleyin:

1. CONFIG_STRICT_MEMORY_RWX'i kaldırın (varsa). 3.18 veya daha yeni bir sürümdeyseniz ve arm64'teyseniz, orada değildir.
2. Şunu ekleyin: CONFIG_DYNAMIC_FTRACE=y, CONFIG_FUNCTION_TRACER=y, CONFIG_IRQSOFF_TRACER=y, CONFIG_FUNCTION_PROFILER=y ve CONFIG_PREEMPT_TRACER=y
3. Yeni çekirdeği yeniden oluşturun ve önyükleyin.
4. Mevcut izleyicileri kontrol etmek için aşağıdakileri çalıştırın:

   cat /sys/kernel/tracing/available_tracers
   

5. Komutun function , irqsoff , preemptoff ve preemptirqsoff döndürdüğünü onaylayın.
6. Dinamik ftrace'in çalıştığından emin olmak için aşağıdakileri çalıştırın:

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

Bu adımları tamamladıktan sonra dinamik ftrace'e, işlev profil oluşturucuya, irqsoff profil oluşturucuya ve preemptoff profil oluşturucuya sahip olursunuz. Güçlü ancak karmaşık oldukları için, bu konulardaki ftrace belgelerini kullanmadan önce okumanızı önemle öneririz . irqsoff ve preemptoff öncelikle sürücülerin kesintileri veya önlemeyi çok uzun süre kapalı bırakabileceğini doğrulamak için kullanışlıdır.

İşlev profili oluşturucu, performans sorunları için en iyi seçenektir ve genellikle bir işlevin nerede çağrıldığını bulmak için kullanılır.

Sayıyı Göster: HDR fotoğraf + dönen vizör

Bu sorunda HDR+ fotoğraf çekmek için Pixel XL kullanmak ve ardından vizörü hemen döndürmek her seferinde sarsıntıya neden oluyordu. Sorunun hatalarını bir saatten kısa sürede ayıklamak için işlev profili oluşturucuyu kullandık. Örneği takip etmek için, izlemelerin zip dosyasını indirin (bu bölümde adı geçen diğer izlemeleri de içerir), dosyayı açın ve trace_30898724.html dosyasını tarayıcınızda açın.

İzleme, ion_client_destroy üzerinde kesintisiz uykuda engellenen kamera sunucusu işlemindeki birkaç iş parçacığını gösterir. Bu pahalı bir işlevdir, ancak iyon istemcilerinin birçok tahsisi kapsaması gerektiğinden çok nadiren çağrılmalıdır. Başlangıçta suç, aslında suçlulardan biri olan Halide'deki Hexagon koduna düştü (her iyon tahsisi için yeni bir müşteri yarattı ve tahsis serbest bırakıldığında bu müşteriyi yok etti, bu da çok pahalıydı). Tüm Hexagon tahsisleri için tek bir iyon istemcisine geçmek durumu iyileştirdi ancak sorun çözülmedi.

Bu noktada ion_client_destroy kimin aradığını bilmemiz gerekiyor, dolayısıyla profil oluşturucuyu kullanmanın zamanı geldi:

1. İşlevler bazen derleyici tarafından yeniden adlandırıldığından, ion_client_destroy orada olduğunu aşağıdakileri kullanarak doğrulayın:

   cat /sys/kernel/tracing/available_filter_functions | grep ion_client_destroy
   

2. Orada olduğunu doğruladıktan sonra ftrace filtresi olarak kullanın:

   echo ion_client_destroy > /sys/kernel/tracing/set_ftrace_filter
   

3. İşlev profili oluşturucuyu açın:

   echo function > /sys/kernel/tracing/current_tracer
   

4. Bir filtre işlevi çağrıldığında yığın izlerini açın:

   echo func_stack_trace > /sys/kernel/tracing/trace_options
   

5. Arabellek boyutunu artırın:

   echo 64000 > /sys/kernel/tracing/buffer_size_kb
   

6. İzlemeyi açın:

   echo 1 > /sys/kernel/tracing/trace_on
   

7. Testi çalıştırın ve izlemeyi alın:

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

8. Çok sayıda yığın izini görmek için izi görüntüleyin:

       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
    

İyon sürücüsünün incelemesine dayanarak, ion_client_destroy rastgele bir çekirdek sürücüsü değil, fd'yi /dev/ion kapatan bir kullanıcı alanı işlevi tarafından spam edildiğini görebiliriz. Android kod tabanını \"/dev/ion\" için arayarak, Hexagon sürücüsüyle aynı şeyi yapan ve her ihtiyaç duyduklarında /dev/ion açıp kapatan (yeni bir ion istemcisi oluşturup yok eden) birkaç satıcı sürücüsü buluyoruz. yeni iyon tahsisi. Bunları işlemin ömrü boyunca tek bir iyon istemcisi kullanacak şekilde değiştirmek hatayı düzeltti.

---

İşlev profili oluşturucudan gelen veriler yeterince spesifik değilse, ftrace izleme noktalarını işlev profili oluşturucuyla birleştirebilirsiniz. ftrace olayları her zamanki gibi tamamen aynı şekilde etkinleştirilebilir ve izinizin arasına eklenecektir. Hata ayıklamak istediğiniz belirli bir işlevde ara sıra uzun, kesintisiz bir uyku varsa bu harikadır: ftrace filtresini istediğiniz işleve ayarlayın, izleme noktalarını etkinleştirin, izleme alın. Ortaya çıkan izi trace2html ile ayrıştırabilir, istediğiniz olayı bulabilir ve ardından ham izde yakındaki yığın izlerini alabilirsiniz.

Lockstat'ı kullanma

Bazen ftrace yeterli olmaz ve çekirdek kilidi çekişmesi gibi görünen bir durumda gerçekten hata ayıklamanız gerekir. Denemeye değer bir çekirdek seçeneği daha var: CONFIG_LOCK_STAT . Bu, Android cihazlarda çalışmak son derece zor olduğundan, çekirdeğin boyutunu çoğu cihazın kaldıramayacağı kadar şişirdiği için son çaredir.

Ancak lockstat, diğer birçok uygulama için yararlı olan hata ayıklama kilitleme altyapısını kullanır. Cihaz getirme üzerinde çalışan herkes, bu seçeneğin her cihazda çalışmasını sağlamanın bir yolunu bulmalıdır çünkü bir zaman " LOCK_STAT açabilseydim, bunun yerine beş dakika içinde bunun sorun olduğunu onaylayabilir veya çürütebilirdim" diye düşündüğünüz bir zaman olacaktır . beş gün."

Sorunu Göster: Çekirdekler SCHED_FIFO olmayanlarla maksimum yükte olduğunda SCHED_FIFO'da durma

Bu sorunda, tüm çekirdekler SCHED_FIFO olmayan iş parçacıklarıyla maksimum yükteyken SCHED_FIFO iş parçacığı durdu. VR uygulamalarında bir fd'de önemli kilit çekişmesi olduğunu gösteren izler bulduk, ancak kullanımda olan fd'yi kolayca tanımlayamadık. Örneği takip etmek için, izlemelerin zip dosyasını indirin (bu bölümde adı geçen diğer izlemeleri de içerir), dosyayı açın ve trace_30905547.html dosyasını tarayıcınızda açın.

Düşük öncelikli bir iş parçacığının ftrace borusuna yazmaya başlaması ve kilidi serbest bırakmadan önce engellenmesi durumunda, ftrace'in kendisinin kilit çekişmesinin kaynağı olduğunu varsaydık. Bu, tamamen yüklü bir cihazı simüle etmek için CPU'lar üzerinde dönen bazı yüksek öncelikli iş parçacıkları ile birlikte ftrace işaretleyicisine yazılan son derece düşük öncelikli iş parçacıklarının bir karışımıyla daha da kötüleşen bir en kötü durum senaryosudur.

Hata ayıklamak için ftrace'i kullanamadığımız için LOCK_STAT çalıştırdık ve uygulamadaki diğer tüm izlemeyi kapattık. Sonuçlar, kilit çekişmesinin aslında ftrace'den kaynaklandığını gösterdi çünkü ftrace çalışmıyorken kilit izinde hiçbir çekişme görünmüyordu.

---

Bir çekirdeği config seçeneğiyle başlatabiliyorsanız, kilit izleme ftrace'e benzer:

1. İzlemeyi etkinleştir:

   echo 1 > /proc/sys/kernel/lock_stat
   

2. Testinizi çalıştırın.
3. İzlemeyi devre dışı bırak:

   echo 0 > /proc/sys/kernel/lock_stat
   

4. İzinizi boşaltın:

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

Ortaya çıkan çıktının yorumlanmasına yardım için <kernel>/Documentation/locking/lockstat.txt adresindeki lockstat belgelerine bakın.

Satıcı izleme noktalarını kullanma

Önce yukarı akış izleme noktalarını kullanın, ancak bazen satıcı izleme noktalarını kullanmanız gerekebilir:

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

İzleme noktaları HAL hizmeti tarafından genişletilebilir ve cihaza özel izleme noktaları/kategoriler eklemenizi sağlar. İzleme noktaları perfetto, atrace/systrace ve cihaz içi sistem izleme uygulamasıyla entegredir.

İzleme noktalarını/kategorileri uygulamaya yönelik API'ler şunlardır:

• listCategories() üretir (vec<TracingCategory> kategoriler);
• activeCategories(vec<string>categories) (Durum durumu) oluşturur;
• DisableAllCategories() (Durum durumu) üretir;

Daha fazla bilgi için AOSP'deki HAL tanımına ve varsayılan uygulamaya bakın: