效能測試

Android 8.0 包含用於測試傳輸量和延遲時間的 Binder 和 hwbinder 效能測試。雖然有許多情境可用於偵測明顯的效能問題，但執行這類情境可能會耗費許多時間，而且通常必須等到系統整合完成後才能取得結果。使用提供的效能測試，可在開發期間更輕鬆地進行測試、提早偵測嚴重問題，並改善使用者體驗。

效能測試包含下列四個類別：

  • 繫結器處理量 (適用於 system/libhwbinder/vts/performance/Benchmark_binder.cpp)
  • 繫結器延遲 (適用於 frameworks/native/libs/binder/tests/schd-dbg.cpp)
  • hwbinder 處理量 (適用於 system/libhwbinder/vts/performance/Benchmark.cpp)
  • hwbinder 延遲時間 (可在 system/libhwbinder/vts/performance/Latency.cpp 中使用)

關於繫結機制和 hwbinder

Binder 和 hwbinder 是 Android 進程間通訊 (IPC) 基礎架構，共用相同的 Linux 驅動程式，但有以下質化差異：

長寬比 繫結機制 hwbinder
目的 為架構提供一般用途的 IPC 配置 與硬體通訊
資源 針對 Android 架構使用方式進行最佳化 最小額外負擔，低延遲
變更前景/背景的排程政策 是 否
傳遞引數 使用 Parcel 物件支援的序列化 使用散布緩衝區，避免複製 Parcel 序列化作業所需資料的額外負擔
優先順序繼承 否 是

Binder 和 hwbinder 程序

systrace 檢視器會顯示下列交易：

圖 1. Systrace 的 Binder 程序圖表。

在上述範例中：

  • 四個 (4) schd-dbg 程序是用戶端程序。
  • 四個 (4) 繫結器程序是伺服器程序 (名稱開頭為 Binder，結尾為序號)。
  • 用戶端程序一律會與用戶端專用的伺服器程序配對。
  • 所有用戶端-伺服器程序組合都會由核心同時獨立排程。

在 CPU 1 中，作業系統核心會執行用戶端來發出要求。接著，它會盡可能使用相同的 CPU 喚醒伺服器程序、處理要求，並在要求完成後切換回內容。

傳輸量與延遲時間

在完美的交易中，用戶端和伺服器程序會順暢切換，因此吞吐量和延遲時間測試不會產生截然不同的訊息。不過，當 OS 核心處理硬體的中斷要求 (IRQ)、等待鎖定，或選擇不立即處理訊息時，就可能會產生延遲泡泡。

圖 2. 由於傳輸量和延遲時間不同，導致延遲時間出現異常。

工作負載測試會產生大量具有不同酬載大小的交易，可針對一般交易時間 (在最佳情況下) 和繫結器可達成的最大工作負載，提供良好的預估值。

相反地，延遲測試不會對酬載執行任何動作，以盡量縮短一般交易時間。我們可以使用交易時間來估算 Binder 額外負擔、針對最壞情況製作統計資料，以及計算延遲時間符合指定期限的交易比率。

處理優先順序反轉

當優先順序較高的執行緒在邏輯上等待優先順序較低的執行緒時，就會發生優先順序倒置。即時 (RT) 應用程式有優先順序倒轉的問題：

圖 3. 即時應用程式中的優先順序反轉。

使用 Linux 完全公平排程器 (CFS) 排程時，即使其他執行緒的優先順序較高，執行緒仍有機會執行。因此，使用 CFS 排程的應用程式會將優先順序倒置視為預期行為，而非問題。不過，如果 Android 架構需要 RT 排程來確保高優先順序執行緒的權限，就必須解決優先順序倒置問題。

繫結器交易期間的優先順序反轉範例 (當 RT 執行緒等待繫結器執行緒提供服務時，會在邏輯上遭到其他 CFS 執行緒封鎖)：

圖 4. 優先順序反轉，即時執行緒遭到封鎖。

為避免阻塞，您可以使用優先順序繼承功能，在 Binder 執行緒處理 RT 用戶端的要求時，暫時將其升級為 RT 執行緒。請注意，RT 排程資源有限，因此應謹慎使用。在具有 n 個 CPU 的系統中，目前的 RT 執行緒數量上限也是 n；如果所有 CPU 都已被其他 RT 執行緒佔用，額外的 RT 執行緒可能需要等待 (因此錯過了截止期限)。

如要解決所有可能的優先順序反轉問題，您可以為繫結器和 hwbinder 使用優先順序繼承。不過，由於繫結器在整個系統中廣泛使用，因此為繫結器交易啟用優先順序繼承功能，可能會讓系統產生大量垃圾郵件，因為系統的 RT 執行緒比可服務的數量還多。

執行吞吐量測試

總處理量測試會針對 Binder/hwbinder 交易總處理量執行。在未超載的系統中，延遲泡沫很少出現，只要迭代次數夠多，就能消除其影響。

  • binder 總處理量測試位於 system/libhwbinder/vts/performance/Benchmark_binder.cpp 中。
  • hwbinder 處理量測試位於 system/libhwbinder/vts/performance/Benchmark.cpp 中。

測試結果

使用不同酬載大小的交易，其吞吐量測試結果範例：

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
  • 時間：表示即時測量的往返延遲時間。
  • CPU 代表 CPU 在測試期間的累積時間。
  • 「Iterations」：表示測試函式執行的次數。

舉例來說，如果酬載大小為 8 個位元組，則：

BM_sendVec_binderize/8         69974 ns      32700 ns      21296

… 繫結器可達到的最大總處理量計算方式如下：

使用 8 個位元組酬載的最大總處理量 = (8 * 21296)/69974 ~= 2.423 b/ns ~= 2.268 Gb/s

測試選項

如要取得 .json 格式的結果，請使用 --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"
    },
   ….
}

執行延遲測試

延遲時間測試會評估用戶端開始初始化交易、切換至伺服器程序進行處理，以及接收結果所需的時間。這項測試也會查看已知的錯誤排程器行為，這些行為可能會對交易延遲時間造成負面影響，例如不支援優先順序繼承或遵循同步標記的排程器。

  • 繫結器延遲測試位於 frameworks/native/libs/binder/tests/schd-dbg.cpp 中。
  • hwbinder 延遲測試位於 system/libhwbinder/vts/performance/Latency.cpp 中。

測試結果

結果 (以 .json 格式顯示) 會顯示平均/最佳/最差延遲時間的統計資料，以及未達時限的次數。

測試選項

延遲時間測試會採用下列選項：

指令 說明
-i value 指定疊代次數。
-pair value 指定程序配對數量。
-deadline_us 2500 以秒為單位指定期限。
-v 取得詳細 (偵錯) 輸出內容。
-trace 在達到截止時間時停止追蹤。

以下各節將詳細說明每個選項、說明用法，並提供範例結果。

指定疊代

以下是大量疊代和詳細輸出內容停用的範例：

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

這些測試結果會顯示以下資訊：

"pair":3
建立一組用戶端和伺服器。
"iterations": 5000
包含 5000 次疊代。
"deadline_us":2500
期限為 2500us (2.5 毫秒)；大部分交易都會符合這個值。
"I": 10000
單一測試迭代包含兩個 (2) 交易：
  • 以一般優先順序處理一筆交易 (CFS other)
  • 依即時優先順序處理一筆交易 (RT-fifo)
5000 次迭代等於總共 10000 筆交易。
"S": 9352
9352 筆交易會在同一個 CPU 中同步。
"R": 0.9352
指示在同一個 CPU 中，用戶端和伺服器同步處理的比例。
"other_ms":{ "avg":0.2 , "wst":2.8 , "bst":0.053, "miss":2, "meetR":0.9996}
由一般優先順序呼叫端發出的所有交易，平均 (avg)、最差 (wst) 和最佳 (bst) 情況。有兩筆交易 miss 超過期限，因此符合率 (meetR) 為 0.9996。
"fifo_ms": { "avg":0.16, "wst":1.5 , "bst":0.067, "miss":0, "meetR":1}
與 other_ms 類似，但適用於由用戶端以 rt_fifo 優先順序發出的交易。fifo_ms 的結果可能 (但不一定) 比 other_ms 好，avg 和 wst 值較低，meetR 較高 (在背景載入時，差異可能更明顯)。

注意：背景負載可能會影響吞吐量結果和延遲測試中的 other_ms 元組。只要背景負載的優先順序低於 RT-fifo，只有 fifo_ms 可能會顯示類似的結果。

指定組合值

每個用戶端程序都會與專屬於用戶端的伺服器程序配對，且每個配對都可能獨立排程至任何 CPU。不過，只要 SYNC 標記為 honor，CPU 遷移就不會在交易期間發生。

請確認系統並未超載！雖然系統超載時會出現高延遲時間，但超載系統的測試結果不會提供實用資訊。如要測試高壓系統，請使用 -pair #cpu-1 (或謹慎使用 -pair #cpu)。使用 -pair n 搭配 n > #cpu 進行測試會造成系統超載，並產生無用的資訊。

指定期限值

經過廣泛的使用者情境測試 (在合格產品上執行延遲時間測試)，我們判定 2.5 毫秒是必須達到的期限。如果新應用程式的要求較高 (例如每秒 1,000 張相片)，這個截止期限值就會變更。

指定詳細輸出內容

使用 -v 選項會顯示詳細輸出內容。例子：

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
  • 服務執行緒會以 SCHED_OTHER 優先順序建立，並在 CPU:1 中搭配 pid 8674 執行。
  • 接著，fifo-caller 會啟動第一筆交易。為了處理這項交易，hwbinder 會將伺服器的優先順序 (pid: 8674 tid: 8676) 升級為 99，並標示為暫時性排程類別 (以 ??? 顯示)。接著，排程器會將伺服器程序放入 CPU:0 執行，並與用戶端同步處理。
  • 第二筆交易呼叫端具有 SCHED_OTHER 優先順序。伺服器會降級，並以 SCHED_OTHER 優先順序為呼叫端提供服務。

使用追蹤功能進行偵錯

您可以指定 -trace 選項來偵錯延遲問題。使用時，延遲測試會在偵測到不良延遲時停止記錄追蹤記錄。例子：

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

下列元件可能會影響延遲時間：

  • Android 建構模式。Eng 模式的速度通常比 userdebug 模式慢。
  • 架構。架構服務如何使用 ioctl 將設定傳送至繫結器？
  • Binder 驅動程式。驅動程式是否支援精細鎖定？是否包含所有性能轉換修正程式？
  • 核心版本。核心的即時處理能力越強，結果就越好。
  • 核心設定。核心設定是否包含 DEBUG 設定，例如 DEBUG_PREEMPT 和 DEBUG_SPIN_LOCK？
  • 核心排程器。核心是否具有節能排程器 (EAS) 或異質多重處理 (HMP) 排程器？是否有任何核心驅動程式 (cpu-freq 驅動程式、cpu-idle 驅動程式、cpu-hotplug 等) 會影響排程器？