效能測試

Android 8.0 包含處理量的繫結器和 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

繫結機制和 hwbinder 是 Android 處理序間通訊 (IPC) 共用相同 Linux 驅動程式但具備 定性差異：

長寬比 繫結機制 Hwbinder
目的 為架構提供一般用途的處理序間通訊 (IPC) 配置 與硬體通訊
資源 已針對 Android 架構使用情形進行最佳化 最低負擔低延遲
變更前景/背景的排程政策 是 否
通過的引數 使用 Parcel 物件支援的序列化作業 使用分散緩衝區，並避免複製 包裹序列化
優先順序繼承 否 是

繫結機制與 hwbinder 程序

Systrace 視覺化工具會顯示交易，如下所示：

圖 1.Systrace 視覺化的繫結器 程序。

在上述範例中：

  • 這四個 schd-dbg 程序是用戶端程序。
  • 四 (4) 繫結器程序是伺服器程序 (名稱以 繫結器，結尾為序號)。
  • 用戶端程序一律會與伺服器程序配對 。
  • 所有用戶端與伺服器程序組合都由核心個別排程 以並行方式處理

在 CPU 1 中，OS 核心會執行用戶端來發出要求。然後 會盡可能使用相同的 CPU 來喚醒伺服器程序， 也會在要求完成後將內容切換回去。

處理量與延遲時間

在完美交易中，用戶端和伺服器程序會切換 因此處理量和延遲時間測試之間 訊息。不過，當 OS 核心處理中斷要求 (IRQ) 時 或只是選擇不處理訊息 延遲泡泡可能會形成

圖 2.造成延遲的泡泡說明 處理量和延遲時間。

處理量測試會產生大量交易 酬載大小，適當地預估一般交易時間 ( 最佳情況)，以及繫結器可達到的最大處理量。

相反地，延遲測試不會對酬載執行任何動作，盡可能降低 一般交易時間我們可以使用交易時間 比較成效最差的情況，據此計算 交易的延遲時間達到指定期限的交易

處理優先順序反轉

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

圖 3.即時優先撤銷優先順序 應用程式。

使用 Linux Fullly Fair Scheduler (CFS) 排程時，執行緒一律會 即使其他執行緒的優先順序較高，也有可能執行。因此 設有「天空藍燈排程」的應用程式會如預期般優先處理優先順序反轉 不會造成問題Android 架構需要 RT 排程的情況 ，保證優先順序較高的執行緒具有優先權 問題解決方式。

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

圖 4.優先反轉、即時封鎖 。

如要避免遭到封鎖，請使用優先繼承功能暫時提報 對 RT 用戶端的要求提供服務時，將繫結器執行緒處理至 RT 執行緒。 請注意，RT 排程的資源有限，建議使用 審慎評估。在搭載 n 個 CPU 的系統中，當前 RT 的數量上限 執行緒也是 n；可能需要等待 ( 則忽略其期限)。

如要解決所有可能的優先順序反轉，可以使用優先等級 。但由於繫結器使用率相當高 進而啟用繫結器交易的優先順序繼承 大量 RT 執行緒，使其無法服務。

執行處理量測試

處理量測試會針對繫結器/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 時的累計時間 進行測試。
  • 疊代代表測試函式的次數 執行狀態

例如，若為 8 位元組酬載：

BM_sendVec_binderize/8         69974 ns      32700 ns      21296

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

8 位元組酬載的 MAX 處理量 = (8 * 21296)/69974 ~= 2.423 b/ns ~= 每秒 2.268 Gb

測試選項

如要取得 .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
包含 5,000 次疊代。
"deadline_us":2500
期限為 2500 我們 (2.5 毫秒)；大多數交易預期會達到 值。
"I": 10000
單一測試疊代包含兩 (2) 筆交易：
  • 依一般優先順序 (CFS other) 區分的交易
  • 依即時優先權排序的一筆交易 (RT-fifo)
，瞭解如何調查及移除這項存取權。 每 5000 次疊代等於一共 10,000 筆交易。
"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 元組合。只有 fifo_ms只要背景載入 低於 RT-fifo 的優先順序

指定配對值

每個用戶端程序都會搭配專屬的伺服器程序， 且可以單獨排程到任何 CPU 上。不過，CPU 交易期間，只要 SYNC 標幟為 honor。

請確保系統不超載！在超載時提供高延遲 因此，超載系統的測試結果沒有那麼實用 可能不準確或不適當如要測試壓力較高的系統，請使用 -pair #cpu-1 (或謹慎使用 -pair #cpu)。使用 進行測試 搭配 n > #cpu 的 -pair n 超載 產生無用的資訊

指定期限值

經過廣泛的使用者情境測試後 ( 認定期限為 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 中加入伺服器程序來執行，並將該程序與 與用戶端相同的 CPU
  • 第二位交易呼叫端有 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 建構模式。工程模式通常比 使用者偵錯模式。
  • 架構。架構服務如何使用 ioctl 要設為繫結器嗎？
  • Binder 驅動程式。驅動程式是否支援精細調整 上鎖？它是否包含所有效能旋轉修補程式？
  • 核心版本：核心即時能力更佳 得到的效果越好
  • 核心設定。核心設定是否包含 DEBUG 設定，例如 DEBUG_PREEMPT 和 是DEBUG_SPIN_LOCK嗎？
  • 核心排程器。核心是否有能源感知能力 排程器 (EAS) 或異質多處理 (HMP) 排程器？執行任何核心 驅動程式 (cpu-freq 個驅動程式、cpu-idle 個驅動程式， cpu-hotplug 等) 是否會影響排程器？