Google is committed to advancing racial equity for Black communities. See how.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Test delle prestazioni

Android 8.0 include test delle prestazioni di binder e hwbinder per velocità effettiva e latenza. Sebbene esistano molti scenari per rilevare problemi di prestazioni percettibili, l'esecuzione di tali scenari può richiedere molto tempo e spesso i risultati non sono disponibili fino a quando un sistema non è stato integrato. L'utilizzo dei test delle prestazioni forniti semplifica i test durante lo sviluppo, rileva i problemi seri in anticipo e migliora l'esperienza dell'utente.

I test delle prestazioni includono le seguenti quattro categorie:

  • binder throughput (disponibile in system/libhwbinder/vts/performance/Benchmark_binder.cpp )
  • latenza binder (disponibile in frameworks/native/libs/binder/tests/schd-dbg.cpp )
  • Velocità effettiva di hwbinder (disponibile in system/libhwbinder/vts/performance/Benchmark.cpp )
  • latenza hwbinder (disponibile in system/libhwbinder/vts/performance/Latency.cpp )

Informazioni su binder e hwbinder

Binder e hwbinder sono infrastrutture di comunicazione inter-processo (IPC) Android che condividono lo stesso driver Linux ma presentano le seguenti differenze qualitative:

Aspetto raccoglitore hwbinder
Scopo Fornire uno schema IPC generico per framework Comunica con l'hardware
Proprietà Ottimizzato per l'utilizzo del framework Android Minimo overhead bassa latenza
Modificare la politica di pianificazione per primo piano / sfondo No
Discussioni che passano Utilizza la serializzazione supportata dall'oggetto Parcel Utilizza buffer di dispersione ed evita il sovraccarico per copiare i dati richiesti per la serializzazione di Parcel
Eredità prioritaria No

Processi legante e hwbinder

Un visualizzatore di systrace mostra le transazioni come segue:

Figura 1. Visualizzazione di Systrace dei processi di legante.

Nell'esempio sopra:

  • I quattro (4) processi schd-dbg sono processi client.
  • I quattro (4) processi binder sono processi server (il nome inizia con Binder e termina con un numero di sequenza).
  • Un processo client è sempre associato a un processo server, che è dedicato al suo client.
  • Tutte le coppie di processi client-server vengono pianificate in modo indipendente dal kernel contemporaneamente.

Nella CPU 1, il kernel del sistema operativo esegue il client per inviare la richiesta. Quindi utilizza la stessa CPU ogni volta che è possibile per riattivare un processo del server, gestire la richiesta e cambiare contesto dopo che la richiesta è stata completata.

Throughput vs. latenza

In una transazione perfetta, in cui il processo client e server cambiano senza problemi, i test di velocità effettiva e latenza non producono messaggi sostanzialmente diversi. Tuttavia, quando il kernel del sistema operativo gestisce una richiesta di interruzione (IRQ) dall'hardware, in attesa di blocchi o semplicemente scegliendo di non gestire immediatamente un messaggio, può formarsi una bolla di latenza.

Figura 2. Bolla di latenza dovuta a differenze di velocità effettiva e latenza.

Il test del throughput genera un gran numero di transazioni con diverse dimensioni di payload, fornendo una buona stima per il tempo di transazione regolare (negli scenari migliori) e il throughput massimo che il binder può raggiungere.

Al contrario, il test di latenza non esegue alcuna azione sul payload per ridurre al minimo il tempo di transazione regolare. Possiamo utilizzare il tempo di transazione per stimare il sovraccarico del binder, fare statistiche per il caso peggiore e calcolare il rapporto di transazioni la cui latenza soddisfa una scadenza specificata.

Gestione delle inversioni di priorità

Un'inversione di priorità si verifica quando un thread con priorità più alta è logicamente in attesa di un thread con priorità inferiore. Le applicazioni in tempo reale (RT) presentano un problema di inversione di priorità:

Figura 3. Inversione delle priorità nelle applicazioni in tempo reale.

Quando si utilizza la pianificazione di Linux Completely Fair Scheduler (CFS), un thread ha sempre la possibilità di essere eseguito anche quando altri thread hanno una priorità maggiore. Di conseguenza, le applicazioni con pianificazione CFS gestiscono l'inversione di priorità come comportamento previsto e non come un problema. Tuttavia, nei casi in cui il framework Android necessita della pianificazione RT per garantire il privilegio dei thread ad alta priorità, è necessario risolvere l'inversione di priorità.

Esempio di inversione di priorità durante una transazione di binder (il thread RT è bloccato logicamente da altri thread CFS durante l'attesa del servizio di un thread di binder):

Figura 4. Inversione di priorità, thread in tempo reale bloccati.

Per evitare blocchi, è possibile utilizzare l'ereditarietà della priorità per intensificare temporaneamente il thread Binder a un thread RT quando serve una richiesta da un client RT. Tieni presente che la pianificazione RT ha risorse limitate e deve essere utilizzata con attenzione. In un sistema con n CPU, anche il numero massimo di thread RT correnti è n ; thread RT aggiuntivi potrebbero dover attendere (e quindi non rispettare le scadenze) se tutte le CPU sono occupate da altri thread RT.

Per risolvere tutte le possibili inversioni di priorità, è possibile utilizzare l'ereditarietà della priorità sia per binder che per hwbinder. Tuttavia, poiché il binder è ampiamente utilizzato nel sistema, l'abilitazione dell'ereditarietà delle priorità per le transazioni del binder potrebbe inviare spam al sistema con più thread RT di quanti ne possa servire.

Esecuzione di test di velocità effettiva

Il test del throughput viene eseguito contro il throughput della transazione binder / hwbinder. In un sistema che non è sovraccarico, le bolle di latenza sono rare e il loro impatto può essere eliminato purché il numero di iterazioni sia sufficientemente elevato.

  • Il test del throughput del binder è in system/libhwbinder/vts/performance/Benchmark_binder.cpp .
  • Il test della velocità effettiva di hwbinder è in system/libhwbinder/vts/performance/Benchmark.cpp .

Risultati del test

Risultati del test di throughput di esempio per transazioni che utilizzano diverse dimensioni di payload:

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
  • Il tempo indica il ritardo di andata e ritorno misurato in tempo reale.
  • CPU indica il tempo accumulato in cui le CPU sono pianificate per il test.
  • Iterazioni indica il numero di volte in cui la funzione di test è stata eseguita.

Ad esempio, per un payload di 8 byte:

BM_sendVec_binderize/8         69974 ns      32700 ns      21296

... il rendimento massimo che il legante può raggiungere è calcolato come:

Throughput MAX con payload di 8 byte = (8 * 21296) / 69974 ~ = 2,423 b / ns ~ = 2,268 Gb / s

Opzioni di prova

Per ottenere risultati in .json, esegui il test con l'argomento --benchmark_format=json :

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"
    },
   ….
}

Esecuzione di test di latenza

Il test di latenza misura il tempo impiegato dal client per iniziare a inizializzare la transazione, passare al processo del server per la gestione e ricevere il risultato. Il test cerca anche comportamenti noti dello scheduler che possono avere un impatto negativo sulla latenza della transazione, come uno scheduler che non supporta l'ereditarietà della priorità o rispetta il flag di sincronizzazione.

  • Il test di latenza del binder è in frameworks/native/libs/binder/tests/schd-dbg.cpp .
  • Il test di latenza di hwbinder è in system/libhwbinder/vts/performance/Latency.cpp .

Risultati del test

I risultati (in .json) mostrano le statistiche per la latenza media / migliore / peggiore e il numero di scadenze perse.

Opzioni di prova

I test di latenza accettano le seguenti opzioni:

Comando Descrizione
-i value Specifica il numero di iterazioni.
-pair value Specificare il numero di coppie di processi.
-deadline_us 2500 Specifica la scadenza in noi.
-v Ottieni output dettagliato (debug).
-trace Interrompi la traccia in caso di raggiungimento di una scadenza.

Le sezioni seguenti descrivono in dettaglio ciascuna opzione, descrivono l'utilizzo e forniscono risultati di esempio.

Specificare le iterazioni

Esempio con un numero elevato di iterazioni e output dettagliato disabilitato:

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"
}

Questi risultati del test mostrano quanto segue:

"pair":3
Crea una coppia client e server.
"iterations": 5000
Include 5000 iterazioni.
"deadline_us":2500
La scadenza è 2500us (2,5 ms); si prevede che la maggior parte delle transazioni raggiunga questo valore.
"I": 10000
Una singola iterazione di test include due (2) transazioni:
  • Una transazione per priorità normale ( CFS other )
  • Una transazione con priorità in tempo reale ( RT-fifo )
5000 iterazioni equivalgono a un totale di 10000 transazioni.
"S": 9352
9352 delle transazioni vengono sincronizzate nella stessa CPU.
"R": 0.9352
Indica il rapporto in base al quale il client e il server vengono sincronizzati insieme nella stessa CPU.
"other_ms":{ "avg":0.2 , "wst":2.8 , "bst":0.053, "miss":2, "meetR":0.9996}
Il caso medio ( avg ), il peggiore ( wst ) e il caso migliore ( bst ) per tutte le transazioni emesse da un normale chiamante prioritario. Due transazioni miss rispettano la scadenza, rendendo il rapporto di incontro ( meetR ) di 0,9996.
"fifo_ms": { "avg":0.16, "wst":1.5 , "bst":0.067, "miss":0, "meetR":1}
Simile a other_ms , ma per transazioni emesse dal client con priorità rt_fifo . È probabile (ma non obbligatorio) che fifo_ms abbia un risultato migliore di other_ms , con valori avg e wst inferiori e un meetR più meetR (la differenza può essere ancora più significativa con il caricamento in background).

Nota: il caricamento in background può influire sul risultato della velocità other_ms e sulla tupla other_ms nel test di latenza. Solo fifo_ms può mostrare risultati simili fintanto che il caricamento in background ha una priorità inferiore rispetto a RT-fifo .

Specifica dei valori di coppia

Ogni processo client è associato a un processo server dedicato per il client e ogni coppia può essere pianificata indipendentemente per qualsiasi CPU. Tuttavia, la migrazione della CPU non dovrebbe avvenire durante una transazione fintanto che il flag SYNC è honor .

Assicurarsi che il sistema non sia sovraccarico! Sebbene sia prevista un'elevata latenza in un sistema sovraccarico, i risultati dei test per un sistema sovraccarico non forniscono informazioni utili. Per testare un sistema con una pressione maggiore, utilizzare -pair #cpu-1 (o -pair #cpu con cautela). Il test utilizzando -pair n con n > #cpu sovraccarica il sistema e genera informazioni inutili.

Specifica dei valori di scadenza

Dopo un test approfondito dello scenario utente (eseguendo il test di latenza su un prodotto qualificato), abbiamo stabilito che la scadenza da rispettare è 2,5 ms. Per nuove applicazioni con requisiti più elevati (come 1000 foto / secondo), questo valore di scadenza cambierà.

Specifica dell'output dettagliato

L'utilizzo dell'opzione -v visualizza un output dettagliato. Esempio:

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
  • Il thread del servizio viene creato con una priorità SCHED_OTHER ed eseguito nella CPU:1 con pid 8674 .
  • La prima transazione viene quindi avviata da un fifo-caller . Per servire questa transazione, hwbinder aggiorna la priorità del server ( pid: 8674 tid: 8676 ) a 99 e la contrassegna anche con una classe di pianificazione transitoria (stampata come ??? ). Lo scheduler inserisce quindi il processo del server in CPU:0 per eseguirlo e lo sincronizza con la stessa CPU con il suo client.
  • Il secondo chiamante della transazione ha una priorità SCHED_OTHER . Il server SCHED_OTHER downgrade e SCHED_OTHER il chiamante con priorità SCHED_OTHER .

Utilizzo della traccia per il debug

È possibile specificare l'opzione -trace per eseguire il debug dei problemi di latenza. Se utilizzato, il test di latenza interrompe la registrazione del tracelog nel momento in cui viene rilevata una latenza errata. Esempio:

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

I seguenti componenti possono influire sulla latenza:

  • Modalità build Android . La modalità Eng è solitamente più lenta della modalità userdebug.
  • Framework . In che modo il servizio framework utilizza ioctl per configurare il binder?
  • Driver legante . Il driver supporta il bloccaggio a grana fine? Contiene tutte le patch di svolta delle prestazioni?
  • Versione del kernel . Migliore è la capacità in tempo reale del kernel, migliori saranno i risultati.
  • Configurazione del kernel . La configurazione del kernel contiene configurazioni DEBUG come DEBUG_PREEMPT e DEBUG_SPIN_LOCK ?
  • Utilità di pianificazione del kernel . Il kernel ha uno scheduler Energy-Aware (EAS) o uno scheduler Heterogeneous Multi-Processing (HMP)? I driver del kernel (driver cpu-freq , driver cpu-idle , cpu-hotplug , ecc.) Influiscono sullo scheduler?