27 Mart 2025'ten itibaren AOSP'yi derlemek ve AOSP'ye katkıda bulunmak için aosp-main yerine android-latest-release kullanmanızı öneririz. Daha fazla bilgi için AOSP'de yapılan değişiklikler başlıklı makaleyi inceleyin.

Bu sayfa, Cloud Translation API ile çevrilmiştir.

ftrace'i kullanma
Koleksiyonlar ile düzeninizi koruyun İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.

ftrace, Linux çekirdeğinin içinde neler olduğunu anlamak için kullanılan bir hata ayıklama aracıdır. Aşağıdaki bölümlerde temel ftrace işlevi, atrace ile ftrace kullanımı (çekirdek etkinliklerini yakalar) ve dinamik ftrace ayrıntılı olarak açıklanmıştır.

systrace'te kullanılamayan gelişmiş ftrace işlevleri hakkında ayrıntılı bilgi için <kernel tree>/Documentation/trace/ftrace.txt adresindeki ftrace dokümanlarına bakın.

atrace ile çekirdek etkinliklerini yakalama

atrace (frameworks/native/cmds/atrace), çekirdek etkinliklerini yakalamak için ftrace'i kullanır. systrace.py (veya Catapult'ın sonraki sürümlerinde run_systrace.py) ise cihazda atrace çalıştırmak için adb'yi kullanır. atrace aşağıdakileri yapar:

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

Atrace'i kullanarak özelliği uygun değere ayarlamak için önyükleme zamanı izleme hariç. Özellik bir bit maskesi olduğundan doğru değerleri belirlemenin uygun başlığa bakmaktan (Android sürümleri arasında değişebilir) başka iyi bir yolu yoktur.

ftrace etkinliklerini etkinleştirme

ftrace sysfs düğümleri /sys/kernel/tracing içindedir ve trace etkinlikleri /sys/kernel/tracing/events içinde kategorilere ayrılır.

Etkinlikleri kategori bazında etkinleştirmek için:

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

Etkinlikleri etkinlik bazında etkinleştirmek için şunları kullanın:

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

sysfs düğümlerine yazarak etkinleştirilen ek etkinlikler, atrace tarafından sıfırlanmaz. Qualcomm cihazı başlatmak için yaygın olarak kullanılan bir yöntem, kgsl (GPU) ve mdss (görüntü ardışık düzeni) izleme noktalarını etkinleştirip 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 manuel olarak yazmak için zaman ayırdıysanız) kullanışlıdır. Yalnızca ftrace'i çalıştırmak için:

Arabellek boyutunu, izlemeniz için yeterince büyük bir değere ayarlayın:
```
echo 96000 > /sys/kernel/tracing/buffer_size_kb
```

İzlemeyi etkinleştirme:

echo 1 > /sys/kernel/tracing/tracing_on

Testinizi çalıştırın, ardından izlemeyi devre dışı bırakın:
```
echo 0 > /sys/kernel/tracing/tracing_on
```

İzlemeyi dökme:

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

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

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

Bu işlem varsayılan olarak trace_file.html dosyasını aynı dizine yazar.

Etkinlikleri ilişkilendirme

Catapult görselleştirmesine ve ftrace günlüğüne aynı anda bakmak genellikle yararlıdır. Örneğin, bazı ftrace etkinlikleri (özellikle tedarikçiye özgü olanlar) Catapult tarafından görselleştirilmez. Ancak Catapult'ın zaman damgaları, izlemedeki ilk etkinliğe veya atrace tarafından dökümü alınan belirli bir zaman damgasına göredir. Ham ftrace zaman damgaları ise Linux çekirdeğinde belirli bir mutlak saat kaynağına dayanır.

Bir Catapult etkinliğindeki belirli bir ftrace etkinliğini bulmak için:

Ham ftrace günlüğünü açın. systrace'in son sürümlerindeki izler varsayılan olarak sıkıştırılır:
- Systrace'inizi --no-compress ile yakaladıysanız bu, html dosyasında BEGIN TRACE ile başlayan bölümde bulunur.
- Aksi takdirde, izlemenin sıkıştırmasını açmak için Catapult ağacından (tracing/bin/html2trace) html2trace'i çalıştırın.
Catapult görselleştirmesinde göreli zaman damgasını bulun.
İzlemenin başında tracing_mark_sync içeren bir satır bulun. Bu, aşağıdaki gibi görünmelidir:
```
<5134>-5134  (-----) [003] ...1    68.104349: tracing_mark_write: trace_event_clock_sync: parent_ts=68.104286
```
Bu satır mevcut değilse (veya ftrace'i atrace olmadan kullandıysanız) zamanlamalar, ftrace günlüklerindeki ilk etkinliğe göre olur.
1. Göreli zaman damgasını (milisaniye cinsinden) parent_ts alanındaki değere (saniye cinsinden) ekleyin.
2. Yeni zaman damgasını arayın.

Bu adımlar sayesinde etkinliğe (veya en azından etkinliğe çok yakın bir yere) ulaşabilirsiniz.

Dinamik ftrace kullanma

systrace ve standart ftrace yeterli olmadığında son bir çare daha vardır: dinamik ftrace. Dinamik ftrace, önyükleme işleminden sonra çekirdek kodunun yeniden yazılmasını içerir. Bu nedenle, güvenlik nedeniyle üretim çekirdeklerinde kullanılamaz. Ancak 2015 ve 2016'daki her zorlu performans hatasının kök nedeni, dinamik ftrace kullanılarak bulunmuştur. Kesintiye uğramayan uyku modunu tetikleyen işleve her bastığınızda çekirdekte bir yığın izlemesi alabileceğiniz için özellikle kesintisiz uyku modunda hata ayıklama için güçlüdür. Ayrıca, kesintileri ve öncelikli kesintileri devre dışı bırakarak bölümlerde hata ayıklama yapabilirsiniz. Bu, sorunları kanıtlamak için çok yararlı olabilir.

Dinamik ftrace'i etkinleştirmek için çekirdeğinizin defconfig dosyasını düzenleyin:

CONFIG_STRICT_MEMORY_RWX (varsa) kaldırılmalıdır. 3.18 veya daha yeni bir sürüm kullanıyorsanız ve arm64 kullanıyorsanız bu seçenek yoktur.
Aşağıdakileri ekleyin: CONFIG_DYNAMIC_FTRACE=y, CONFIG_FUNCTION_TRACER=y, CONFIG_IRQSOFF_TRACER=y, CONFIG_FUNCTION_PROFILER=y ve CONFIG_PREEMPT_TRACER=y
Yeni çekirdeği yeniden oluşturup önyükleyin.
Mevcut izleyicileri kontrol etmek için aşağıdakileri çalıştırın:
```
cat /sys/kernel/tracing/available_tracers
```
Komutun function, irqsoff, preemptoff ve preemptirqsoff döndürdüğünü onaylayın.
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, işlev profilleyici, irqsoff profilleyici ve preemptoff profilleyiciyi kullanabilirsiniz. Güçlü ancak karmaşık oldukları için bu konuları kullanmadan önce bu konularla ilgili ftrace belgelerini okumanızı önemle tavsiye ederiz. irqsoff ve preemptoff, öncelikle sürücülerin kesintileri veya önceliği çok uzun süre kapalı bırakabileceğini doğrulamak için yararlıdır.

Performans sorunları için en iyi seçenek olan işlev profilleyici, genellikle bir işlevin nerede çağrıldığını bulmak için kullanılır.

Sorunu göster: HDR fotoğraf + dönen vizör

Bu sorunda, HDR+ fotoğraf çekmek için Pixel XL'i kullanan ve ardından vizörü hemen döndüren kullanıcılar her seferinde takılmayla karşılaşıyordu. Sorunu bir saatten kısa sürede düzeltmek için işlev profilleyiciyi kullandık. Örneği takip etmek için izlemeleri içeren zip dosyasını indirin (bu bölümde bahsedilen diğer izlemeleri de içerir), dosyayı açın ve trace_30898724.html dosyasını tarayıcınızda açın.

İzleme, kamera sunucusu işleminde ion_client_destroy üzerinde kesintisiz uykuda engellenen birkaç iş parçacığı olduğunu gösterir. Bu pahalı bir işlevdir ancak ion istemcileri birçok ayırmayı içereceğinden çok seyrek çağrılmalıdır. Başlangıçta suç Halide'deki Hexagon koduna atfedildi. Bu kod gerçekten de suçlulardan biriydi (her iyon tahsisi için yeni bir istemci oluşturup tahsis serbest bırakıldığında bu istemciyi imha ediyordu ve bu işlem çok pahalıydı). Tüm Hexagon atamalarında tek bir ion istemciye geçmek durumu iyileştirdi ancak takılma sorunu düzeltilmedi.

Bu noktada ion_client_destroy işlevini kimin çağırdığını bilmemiz gerekiyor. Bu nedenle işlev profilleyiciyi kullanmamız gerekiyor:

İşlevler bazen derleyici tarafından yeniden adlandırıldığından, ion_client_destroy'ün mevcut olup olmadığını şu şekilde onaylayın:
```
cat /sys/kernel/tracing/available_filter_functions | grep ion_client_destroy
```
Varlığını doğruladıktan sonra ftrace filtresi olarak kullanın:
```
echo ion_client_destroy > /sys/kernel/tracing/set_ftrace_filter
```

İşlev profilleyiciyi etkinleştirme:

echo function > /sys/kernel/tracing/current_tracer

Bir filtre işlevi her çağrıldığında yığın izlemelerini etkinleştirme:
```
echo func_stack_trace > /sys/kernel/tracing/trace_options
```

Arabellek boyutunu artırın:

echo 64000 > /sys/kernel/tracing/buffer_size_kb

İzlemeyi etkinleştirme:
```
echo 1 > /sys/kernel/tracing/trace_on
```

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

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

Çok sayıda yığın izlemeyi görmek için izlemeyi 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

ion sürücüsünün incelenmesine göre, ion_client_destroy'ün rastgele bir çekirdek sürücüsü tarafından değil, /dev/ion için bir fd'yi kapatan bir kullanıcı alanı işlevi tarafından spam'lendiği görülüyor. Android kod tabanında \"/dev/ion\" için arama yaptığımızda, Hexagon sürücüsüyle aynı şeyi yapan ve yeni bir ion tahsisine ihtiyaç duyduklarında her seferinde /dev/ion'ı açan/kapayan (yeni bir ion istemcisi oluşturup yok eden) çeşitli tedarikçi sürücüleri tespit ediyoruz. Bu değerleri, sürecin yaşam boyu tek bir ion istemcisi kullanacak şekilde değiştirerek hatayı düzelttik.

İşlev profilleyiciden alınan veriler yeterince spesifik değilse ftrace izleme noktalarını işlev profilleyiciyle birleştirebilirsiniz. ftrace etkinlikleri, her zamanki gibi etkinleştirilebilir ve izlemenizle birlikte yerleştirilir. Hata ayıklama yapmak istediğiniz belirli bir işlevde zaman zaman kesintisiz uzun bir uyku varsa bu yöntemi kullanabilirsiniz: ftrace filtresini istediğiniz işleve ayarlayın, izleme noktalarını etkinleştirin, izleme yapın. Elde edilen izlemeyi trace2html ile ayrıştırabilir, istediğiniz etkinliği bulabilir ve ardından ham izlemede yakındaki yığın izlemelerini alabilirsiniz.

lockstat'i kullanma

Bazen ftrace yeterli olmaz ve çekirdek kilidi anlaşmazlığı gibi görünen bir sorunda gerçekten hata ayıklama yapmanız gerekir. Denemeye değer başka bir çekirdek seçeneği daha vardır: CONFIG_LOCK_STAT. Android cihazlarda çalışmasını sağlamak son derece zor olduğu için bu yöntem son çare olarak kullanılır. Bunun nedeni, çekirdeğin boyutunu çoğu cihazın kaldırabileceğinden daha fazla şişirmesidir.

Ancak lockstat, diğer birçok uygulama için yararlı olan hata ayıklama kilitleme altyapısını kullanır. Cihazları kullanıma sunma konusunda çalışan herkesin, bu seçeneği her cihazda çalıştırmanın bir yolunu bulması gerekir. Çünkü "Keşke LOCK_STAT'yi açabilsem de bu sorunu beş gün yerine beş dakikada doğrulayabilsem veya redd edebilsem" diye düşüneceğiniz bir zaman gelecek.

Sorunu göster: Çekirdekler SCHED_FIFO olmayan bir durumdayken maksimum yükteyken SCHED_FIFO'da duraksama

Bu sorunda, tüm çekirdekler SCHED_FIFO olmayan iş parçacıklarıyla maksimum yükteyken SCHED_FIFO iş parçacığı duraklatıldı. VR uygulamalarında bir fd üzerinde önemli kilitlenme çekişmesi gösteren izlere sahiptik ancak kullanılan fd'yi kolayca tanımlayamadık. Örneği takip etmek için izlemeleri içeren zip dosyasını indirin (bu bölümde bahsedilen diğer izlemeler de bu dosyada yer alır), dosyayı açın ve trace_30905547.html dosyasını tarayıcınızda açın.

Düşük öncelikli bir iş parçacığı ftrace borusuna yazmaya başladığında ve kilidi bırakamadan önce öncelikli hale getirildiğinde kilit anlaşmazlığının kaynağının ftrace olduğunu varsaydık. Bu, tamamen yüklü bir cihazı simüle etmek için CPU'larda çalışan bazı yüksek öncelikli iş parçacıklarının yanı sıra ftrace işaretçisine yazan son derece düşük öncelikli iş parçacıklarının bir karışımıyla daha da kötüleştirilen en kötü durum senaryosudur.

Hata ayıklama için ftrace'i kullanamadığımızdan LOCK_STAT'ü çalıştırdık ve ardından uygulamadaki diğer tüm izlemeleri devre dışı bıraktık. Sonuçlar, kilit anlaşmazlığının aslında ftrace'ten kaynaklandığını gösterdi çünkü ftrace çalışmadığında anlaşmazlıkların hiçbiri kilit izlemede görünmedi.

Bir çekirdeği config seçeneğiyle önyükleyebiliyorsanız kilit izleme, ftrace'e benzer:

İzlemeyi etkinleştirme:
```
echo 1 > /proc/sys/kernel/lock_stat
```
Testinizi çalıştırın.
İzlemeyi devre dışı bırakma:
```
echo 0 > /proc/sys/kernel/lock_stat
```

İzlemenizi dökme:

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

Elde edilen çıkışı yorumlama konusunda yardım için <kernel>/Documentation/locking/lockstat.txt adresindeki lockstat dokümanlarına bakın.

Tedarikçi firma izleme noktalarını kullanma

Öncelikle yayın öncesi izleme noktalarını kullanın ancak bazen tedarikçi firma izleme noktalarını kullanmanız gerekir:

  { "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. Bu sayede cihaza özel izleme noktaları/kategoriler ekleyebilirsiniz. İzleme noktaları, perfetto, atrace/systrace ve cihaz üzerinde sistem izleme uygulamasıyla entegredir.

İzleme noktalarını/kategorileri uygulamak için kullanılan API'ler şunlardır:

listCategories(), (vec<TracingCategory> categories) değerini döndürür.
enableCategories(vec<string> categories) (Status status) değerini döndürür;
disableAllCategories() (Durum durumu) oluşturur;

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

ftrace'i kullanma Koleksiyonlar ile düzeninizi koruyun İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.