Performans testi

Android 8.0, işleme hızı ve Algılanan performansı tespit etmek için birçok senaryo mevcut olsa da bu tür senaryoları yürütmek zaman alabilir ve sonuçlar genellikle ve sistem entegre edilene kadar kullanılamaz. Sağlanan performansı kullanarak testleri, geliştirme sırasında test yapılmasını, ciddi sorunları tespit etmeyi kolaylaştırır ve kullanıcı deneyimini iyileştirebilirsiniz.

Performans testleri aşağıdaki dört kategoriyi içerir:

• bağlayıcı işleme hızı ( system/libhwbinder/vts/performance/Benchmark_binder.cpp) olarak değiştirildi
• bağlayıcı gecikmesi ( frameworks/native/libs/binder/tests/schd-dbg.cpp) olarak değiştirildi
• hwbinder işleme hızı ( system/libhwbinder/vts/performance/Benchmark.cpp) olarak değiştirildi
• hwbinder gecikmesi (şurada kullanılabilir: system/libhwbinder/vts/performance/Latency.cpp) olarak değiştirildi

Binder ve hwbinder hakkında

Binder ve hwbinder, Android işlemler arası iletişimdir (IPC). aynı Linux sürücüsünü paylaşan ancak aşağıdakilere sahip altyapılar nitel farklılıklar:

Bağlayıcı ve Hwbinder işlemleri

Sistem izleme görselleştirici, işlemleri aşağıdaki gibi gösterir:

Yukarıdaki örnekte:

• Dört (4) schd-dbg işlemi, istemci işlemleridir.
• Dört (4) bağlayıcı işlemi, sunucu işlemleridir (ad Bağlayıcı'yı içerir ve bir sıra numarasıyla biter).
• İstemci işlemi her zaman bir sunucu işlemiyle eşleştirilir; bu işlem teslim etmeye odaklandığı teslimatı öğrendiniz.
• Tüm istemci-sunucu işlem çiftleri, çekirdek tarafından bağımsız olarak programlanır elde edebilirsiniz.

CPU 1'de işletim sistemi çekirdeği, isteği göndermek için istemciyi yürütür. O zaman mümkün olduğunda aynı CPU'yu kullanır. isteğinde bulunur ve istek tamamlandıktan sonra bağlam eski haline döner.

İşleme hızı ve gecikme

İstemci ve sunucunun sürecin birbirine geçiş yaptığı mükemmel bir işlem işleme hızı ve gecikme testleri de büyük oranda farklı mesaj. Bununla birlikte, işletim sistemi çekirdeği bir kesinti isteğini (IRQ) işlerken kilitleri beklerken ya da yalnızca belirli bir mesajı işlememeyi hemen bir gecikme balonu oluşabilir.

İşleme hızı testi, farklı boyutlarda çok sayıda işlem oluşturur yük boyutlarını sağlar ve normal işlem süresi için iyi bir tahmin sağlar en iyi senaryoları) ve bağlayıcının ulaşabileceği maksimum işleme hızını belirler.

Buna karşılık gecikme testi, yük üzerinde en aza normal işlem süresidir. Bağlayıcıyı tahmin etmek için işlem süresini kullanabiliriz. en kötü durum için istatistik çıkaracak ve her bir senaryonun her birinin Gecikmesi belirli bir son tarihi karşılayan işlemlerdir.

Öncelikleri ters çevirme işlemlerini yapma

Öncelikli ters çevirme, daha yüksek önceliğe sahip bir ileti dizisi mantıksal olarak daha düşük önceliğe sahip bir ileti dizisi bekleniyor. Gerçek zamanlı (RT) uygulamaların, öncelikli ters çevirme sorunu:

Linux Fullly Fair Scheduler (CFS) planlaması kullanılırken her zaman bir iş parçacığı daha yüksek önceliğe sahip olan durumlarda bile yayınlanabilir. Sonuç olarak, CFS programlaması olan uygulamalar, önceliği ters çevirmeyi beklenen davranış gibi ele alır bir sorun yaratmaz. Android çerçevesinin RT planlamasına ihtiyaç duyduğu durumlarda Ayrıca, yüksek öncelikli ileti dizilerinin ayrıcalığını garanti etmek için, çözümlenmesi gerekir.

Bağlayıcı işlemi sırasında örnek öncelik ters çevirme (RT iş parçacığı bir bağlayıcı iş parçacığının hizmet):

Engellemeleri önlemek amacıyla, öncelik devralma özelliğini kullanarak geçici bir süreliğine Bağlayıcı iş parçacığı, RT istemcisinden gelen bir isteğe hizmet ettiğinde RT iş parçacığına bağlanır. RT planlamasının sınırlı kaynaklara sahip olduğunu ve kullanılması gerektiğini unutmayın. dikkatli olun. n CPU'lu bir sistemde, mevcut maksimum RT sayısı ileti dizileri de n; ek RT iş parçacığının beklemesi gerekebilir (ve dolayısıyla teslim tarihlerini kaçırma ihtimaliniz vardır.

Mümkün olan tüm öncelik ters çevirme işlemlerini çözmek için önceliği kullanabilirsiniz hem bağlayıcı hem de hwbinder için devralma olmadığından emin olun. Ancak bağlayıcı yaygın olarak bağlayıcı işlemler için öncelik devralmayı etkinleştirmek, sisteme, hizmet verebileceğinden daha fazla RT ileti dizisi ile spam gönderme.

İşleme hızı testlerini çalıştırma

İşleme hızı testi, bağlayıcı/hwbinder işlem işleme hızına karşı çalıştırılır. İçinde bir sistem olduğundan, gecikme balonları nadir görülür ve etkisi iterasyonların sayısı yeterince yüksek olduğu sürece kaldırılabilir.

• Bağlayıcı işleme hızı testi hazır system/libhwbinder/vts/performance/Benchmark_binder.cpp.
• hwbinder işleme hızı testi hazır system/libhwbinder/vts/performance/Benchmark.cpp.

Test sonuçları

Farklı yük kullanan işlemler için örnek işleme hızı testi sonuçları boyutlar:

Benchmark                      Time          CPU           Iterations
---------------------------------------------------------------------
BM_sendVec_binderize/4         70302 ns      32820 ns      21054
BM_sendVec_binderize/8         69974 ns      32700 ns      21296
BM_sendVec_binderize/16        70079 ns      32750 ns      21365
BM_sendVec_binderize/32        69907 ns      32686 ns      21310
BM_sendVec_binderize/64        70338 ns      32810 ns      21398
BM_sendVec_binderize/128       70012 ns      32768 ns      21377
BM_sendVec_binderize/256       69836 ns      32740 ns      21329
BM_sendVec_binderize/512       69986 ns      32830 ns      21296
BM_sendVec_binderize/1024      69714 ns      32757 ns      21319
BM_sendVec_binderize/2k        75002 ns      34520 ns      20305
BM_sendVec_binderize/4k        81955 ns      39116 ns      17895
BM_sendVec_binderize/8k        95316 ns      45710 ns      15350
BM_sendVec_binderize/16k      112751 ns      54417 ns      12679
BM_sendVec_binderize/32k      146642 ns      71339 ns       9901
BM_sendVec_binderize/64k      214796 ns     104665 ns       6495

• Süre, gerçek zamanlı olarak ölçülen gidiş dönüş gecikmesini gösterir.
• CPU, CPU'ların planlandığı birikmiş süreyi gösterir seçeceğim.
• Yinelemeler, test işlevinin kaç kez yürütüldü.

Örneğin, 8 baytlık bir yük için:

BM_sendVec_binderize/8         69974 ns      32700 ns      21296

Bağlayıcının ulaşabileceği maksimum işleme hızı şu şekilde hesaplanır:

8 bayt yük ile MAX işleme hızı = (8 * 21296)/69974 ~= 2,423 b/ns ~= 2,268 Gb/sn

Test seçenekleri

Sonuçları .json dosyasında almak için --benchmark_format=json bağımsız değişkeni:

libhwbinder_benchmark --benchmark_format=json
{
  "context": {
    "date": "2017-05-17 08:32:47",
    "num_cpus": 4,
    "mhz_per_cpu": 19,
    "cpu_scaling_enabled": true,
    "library_build_type": "release"
  },
  "benchmarks": [
    {
      "name": "BM_sendVec_binderize/4",
      "iterations": 32342,
      "real_time": 47809,
      "cpu_time": 21906,
      "time_unit": "ns"
    },
   ….
}

Gecikme testleri çalıştırma

Gecikme testi, istemcinin başlatılmasına kadar geçen süreyi ölçer. işlemi başlatma, işleme için sunucu işlemine geçme ve sonucu alır. Test, bilinen kötü planlayıcı davranışlarını da inceler. işlem gecikmesini olumsuz yönde etkileyebilir (örneğin, öncelikli devralmayı desteklemeli veya senkronizasyon işaretini dikkate almamalıdır.

• Bağlayıcı gecikmesi testi hazır frameworks/native/libs/binder/tests/schd-dbg.cpp
• Hwbinder gecikme testi şimdi system/libhwbinder/vts/performance/Latency.cpp

Test sonuçları

Sonuçlar (.json'da) ortalama/en iyi/en kötü gecikme ve tespit edebilirsiniz.

Test seçenekleri

Gecikme testlerinde aşağıdaki seçenekler sunulur:

Aşağıdaki bölümlerde her bir seçenek ayrıntılı olarak açıklanmakta, kullanımı açıklanmaktadır ve örnek sonuçlar.

İterasyonları belirtme

Çok sayıda yinelemenin ve ayrıntılı çıkışın devre dışı bırakıldığı örnek:

libhwbinder_latency -i 5000 -pair 3
{
"cfg":{"pair":3,"iterations":5000,"deadline_us":2500},
"P0":{"SYNC":"GOOD","S":9352,"I":10000,"R":0.9352,
  "other_ms":{ "avg":0.2 , "wst":2.8 , "bst":0.053, "miss":2, "meetR":0.9996},
  "fifo_ms": { "avg":0.16, "wst":1.5 , "bst":0.067, "miss":0, "meetR":1}
},
"P1":{"SYNC":"GOOD","S":9334,"I":10000,"R":0.9334,
  "other_ms":{ "avg":0.19, "wst":2.9 , "bst":0.055, "miss":2, "meetR":0.9996},
  "fifo_ms": { "avg":0.16, "wst":3.1 , "bst":0.066, "miss":1, "meetR":0.9998}
},
"P2":{"SYNC":"GOOD","S":9369,"I":10000,"R":0.9369,
  "other_ms":{ "avg":0.19, "wst":4.8 , "bst":0.055, "miss":6, "meetR":0.9988},
  "fifo_ms": { "avg":0.15, "wst":1.8 , "bst":0.067, "miss":0, "meetR":1}
},
"inheritance": "PASS"
}

Bu test sonuçları aşağıdakileri gösterir:

"pair":3

Bir istemci ve sunucu çifti oluşturur.

"iterations": 5000

5.000 yineleme içerir.

"deadline_us":2500

Son tarih 2500us'tur (2,5 ms); çoğu işlemin bu oranı karşılaması bekleniyor değer.

"I": 10000

Tek bir test yinelemesinde iki (2) işlem bulunur:

• Normal önceliğe göre bir işlem (CFS other)
• Gerçek zamanlı önceliğe göre bir işlem (RT-fifo)

ziyaret edin. 5.000 yineleme, toplam 10.000 işleme eşittir.

"S": 9352

İşlemlerden 9.352'si aynı CPU'da senkronize edilir.

"R": 0.9352

İstemci ile sunucunun aynı CPU'ya sahip olursunuz.

"other_ms":{ "avg":0.2 , "wst":2.8 , "bst":0.053, "miss":2, "meetR":0.9996}

Ortalama (avg), en kötü (wst) ve en iyi (bst) destek kaydı, normal öncelikli bir arayan tarafından gerçekleştirilen tüm işlemler için geçerlidir. İki işlem, teslim tarihinin miss olmasını sağlayarak karşılanma oranına ulaştı (meetR) 0,9996.

"fifo_ms": { "avg":0.16, "wst":1.5 , "bst":0.067, "miss":0, "meetR":1}

other_ms ile benzer, ancak şu hesabı ile müşteri tarafından gerçekleştirilen işlemler için: rt_fifo öncelik. Muhtemelen (zorunlu değildir), fifo_ms, other_ms koluna kıyasla daha iyi ve daha düşük avg ve wst değerleri ve daha yüksek bir meetR (Aradaki fark, arka planda yükleme olduğunda daha da belirgin olabilir).

Not: Arka planda yükleme, işleme hızını etkileyebilir sonucu ve gecikme testindeki other_ms demetini gösterir. Yalnızca Arka plan yüklemesinin devam ettiği sürece fifo_ms benzer sonuçlar gösterebilir. RT-fifo daha düşük önceliğe sahiptir.

Eşleme değerlerini belirtin

Her istemci işlemi, istemciye özel bir sunucu işlemiyle eşlenir ve her çift herhangi bir CPU'ya göre bağımsız olarak programlanabilir. Ancak CPU, SYNC işareti etkin olduğu sürece işlem sırasında taşıma işleminin honor

Sistemin aşırı yüklenmediğinden emin olun. Aşırı yüklemede yüksek gecikme bir sistem olması bekleniyor, ama aşırı yüklenmiş bir sisteme ait test sonuçları yararlı ekleyebilirsiniz. Daha yüksek basınca sahip bir sistemi test etmek için -pair #cpu-1 (veya -pair #cpu dikkatli bir şekilde) kullanın. Şunu kullanarak test etme: n > #cpu ile -pair n, ve gereksiz bilgiler oluşturur.

Son tarih değerlerini belirtin

Kapsamlı kullanıcı senaryo testinden sonra (diğer bir deyişle nitelikli bir ürün), 2,5 ms olarak belirlenen son teslim tarihinin 2,5 ms olduğunu belirledik. Yeni daha yüksek gereksinimleri olan uygulamalarda (örneğin, 1000 fotoğraf/saniye), bu farklı bir tarih görürsünüz.

Ayrıntılı çıkış belirt

-v seçeneği kullanıldığında ayrıntılı çıkış gösterilir. Örnek:

libhwbinder_latency -i 1 -v

--------------------------------------------------
service      pid: 8674 tid: 8674 cpu: 1
SCHED_OTHER 0
--------------------------------------------------
main         pid: 8673 tid: 8673 cpu: 1

--------------------------------------------------
client       pid: 8677 tid: 8677 cpu: 0
SCHED_OTHER 0

--------------------------------------------------
fifo-caller  pid: 8677 tid: 8678 cpu: 0
SCHED_FIFO  99

--------------------------------------------------
hwbinder     pid: 8674 tid: 8676 cpu: 0
???         99
--------------------------------------------------
other-caller pid: 8677 tid: 8677 cpu: 0
SCHED_OTHER 0

--------------------------------------------------
hwbinder     pid: 8674 tid: 8676 cpu: 0
SCHED_OTHER 0

• Hizmet ileti dizisi SCHED_OTHER öncelikli ve pid 8674 ile CPU:1 uygulamasında çalıştır.
• İlk işlem, fifo-caller. Sağlayıcı, bu işlemi gerçekleştirmek için sunucunun (pid: 8674 tid: 8676) önceliğini 99 olarak ayarlar ve ayrıca geçici bir planlama sınıfıyla (??? olarak yazdırılır). Planlayıcı ardından, sunucu işlemini CPU:0 içine koyar ve aynı CPU'ya sahip olduğunu gösterir.
• İkinci işlem çağrısını yapan ise SCHED_OTHER öncelik. Sunucu kendini eski sürüme geçirir ve SCHED_OTHER öncelikli arayan.

Hata ayıklama için izlemeyi kullan

Gecikme sorunlarında hata ayıklamak için -trace seçeneğini belirleyebilirsiniz. Zaman kullanıldığında, gecikme testi kötü olduğunda iz günlüğü kaydını durdurur. tespit edildiğinden emin olun. Örnek:

atrace --async_start -b 8000 -c sched idle workq binder_driver sync freq
libhwbinder_latency -deadline_us 50000 -trace -i 50000 -pair 3
deadline triggered: halt ∓ stop trace
log:/sys/kernel/debug/tracing/trace

Aşağıdaki bileşenler gecikmeyi etkileyebilir:

• Android derleme modu Mühendislik modu genellikle şundan daha yavaştır: kullanıcı hata ayıklama modu ile ilgilidir.
• Çerçeve. Çerçeve hizmeti Bağlayıcıyı yapılandırmak için ioctl?
• Bağlayıcı sürücüsü. Sürücü, ayrıntılı kilitleniyor mu? Tüm performans dönüştürme yamalarını içeriyor mu?
• Çekirdek sürümü. Çekirdekteki gerçek zamanlı çalışma kapasitesi olursa o kadar iyi sonuçlar elde edersiniz.
• Çekirdek yapılandırması. Çekirdek yapılandırmasında DEBUG_PREEMPT ve gibi DEBUG yapılandırmaları DEBUG_SPIN_LOCK mi?
• Çekirdek planlayıcı. Çekirdekte Energy-Aware özelliği var mı? planlayıcı (EAS) veya Heterojen Çoklu İşleme (HMP) planlayıcısı mı? Herhangi bir çekirdek oluştur sürücü (cpu-freq sürücü, cpu-idle sürücü, cpu-hotplug vb.) planlayıcıyı etkiler mi?