परफ़ॉर्मेंस की जांच करना

एंड्रॉइड 8.0 में थ्रूपुट और विलंबता के लिए बाइंडर और एचडब्ल्यूबाइंडर प्रदर्शन परीक्षण शामिल हैं। जबकि प्रत्यक्ष प्रदर्शन समस्याओं का पता लगाने के लिए कई परिदृश्य मौजूद हैं, ऐसे परिदृश्यों को चलाने में समय लग सकता है और सिस्टम एकीकृत होने तक परिणाम अक्सर अनुपलब्ध होते हैं। प्रदान किए गए प्रदर्शन परीक्षणों का उपयोग करने से विकास के दौरान परीक्षण करना, गंभीर समस्याओं का पहले ही पता लगाना और उपयोगकर्ता अनुभव में सुधार करना आसान हो जाता है।

प्रदर्शन परीक्षणों में निम्नलिखित चार श्रेणियां शामिल हैं:

• बाइंडर थ्रूपुट ( 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 में उपलब्ध)

बाइंडर और ह्वबाइंडर के बारे में

बाइंडर और ह्वबिंडर एंड्रॉइड इंटर-प्रोसेस कम्युनिकेशन (आईपीसी) इंफ्रास्ट्रक्चर हैं जो समान लिनक्स ड्राइवर साझा करते हैं लेकिन इनमें निम्नलिखित गुणात्मक अंतर हैं:

बाइंडर और ह्वबाइंडर प्रक्रियाएं

एक सिस्ट्रेस विज़ुअलाइज़र लेनदेन को निम्नानुसार प्रदर्शित करता है:

उपरोक्त उदाहरण में:

• चार (4) schd-dbg प्रक्रियाएँ क्लाइंट प्रक्रियाएँ हैं।
• चार (4) बाइंडर प्रक्रियाएँ सर्वर प्रक्रियाएँ हैं (नाम बाइंडर से शुरू होता है और अनुक्रम संख्या के साथ समाप्त होता है)।
• एक क्लाइंट प्रक्रिया को हमेशा एक सर्वर प्रक्रिया के साथ जोड़ा जाता है, जो अपने क्लाइंट को समर्पित होती है।
• सभी क्लाइंट-सर्वर प्रक्रिया जोड़े कर्नेल द्वारा समवर्ती रूप से स्वतंत्र रूप से निर्धारित किए जाते हैं।

सीपीयू 1 में, ओएस कर्नेल अनुरोध जारी करने के लिए क्लाइंट को निष्पादित करता है। इसके बाद जब भी संभव हो सर्वर प्रक्रिया को सक्रिय करने, अनुरोध को संभालने और अनुरोध पूरा होने के बाद संदर्भ को वापस स्विच करने के लिए यह उसी सीपीयू का उपयोग करता है।

थ्रूपुट बनाम विलंबता

एक आदर्श लेनदेन में, जहां क्लाइंट और सर्वर प्रक्रिया निर्बाध रूप से स्विच होती है, थ्रूपुट और विलंबता परीक्षण पर्याप्त रूप से भिन्न संदेश उत्पन्न नहीं करते हैं। हालाँकि, जब ओएस कर्नेल हार्डवेयर से इंटरप्ट रिक्वेस्ट (आईआरक्यू) को संभाल रहा है, लॉक की प्रतीक्षा कर रहा है, या बस किसी संदेश को तुरंत नहीं संभालने का विकल्प चुन रहा है, तो एक विलंबता बुलबुला बन सकता है।

थ्रूपुट परीक्षण विभिन्न पेलोड आकारों के साथ बड़ी संख्या में लेनदेन उत्पन्न करता है, जो नियमित लेनदेन समय (सर्वोत्तम स्थिति में) के लिए एक अच्छा अनुमान प्रदान करता है और बाइंडर अधिकतम थ्रूपुट प्राप्त कर सकता है।

इसके विपरीत, विलंबता परीक्षण नियमित लेनदेन समय को कम करने के लिए पेलोड पर कोई कार्रवाई नहीं करता है। हम बाइंडर ओवरहेड का अनुमान लगाने के लिए लेनदेन समय का उपयोग कर सकते हैं, सबसे खराब स्थिति के लिए आंकड़े बना सकते हैं, और उन लेनदेन के अनुपात की गणना कर सकते हैं जिनकी विलंबता एक निर्दिष्ट समय सीमा को पूरा करती है।

प्राथमिकता व्युत्क्रमण को संभालें

प्राथमिकता उलटा तब होता है जब उच्च प्राथमिकता वाला थ्रेड तार्किक रूप से कम प्राथमिकता वाले थ्रेड की प्रतीक्षा कर रहा होता है। वास्तविक समय (आरटी) अनुप्रयोगों में प्राथमिकता व्युत्क्रमण समस्या होती है:

लिनक्स कंप्लीट्ली फेयर शेड्यूलर (सीएफएस) शेड्यूलिंग का उपयोग करते समय, एक थ्रेड को हमेशा चलने का मौका मिलता है, भले ही अन्य थ्रेड की प्राथमिकता अधिक हो। परिणामस्वरूप, सीएफएस शेड्यूलिंग वाले एप्लिकेशन प्राथमिकता व्युत्क्रम को अपेक्षित व्यवहार के रूप में संभालते हैं, समस्या के रूप में नहीं। ऐसे मामलों में जहां एंड्रॉइड फ्रेमवर्क को उच्च प्राथमिकता वाले थ्रेड्स के विशेषाधिकार की गारंटी के लिए आरटी शेड्यूलिंग की आवश्यकता होती है, प्राथमिकता व्युत्क्रम को हल किया जाना चाहिए।

बाइंडर लेनदेन के दौरान उदाहरण प्राथमिकता व्युत्क्रम (बाइंडर थ्रेड की सेवा की प्रतीक्षा करते समय आरटी थ्रेड को अन्य सीएफएस थ्रेड द्वारा तार्किक रूप से अवरुद्ध किया जाता है):

रुकावटों से बचने के लिए, आप बाइंडर थ्रेड को अस्थायी रूप से आरटी थ्रेड में बढ़ाने के लिए प्राथमिकता विरासत का उपयोग कर सकते हैं जब यह आरटी क्लाइंट से अनुरोध की सेवा करता है। ध्यान रखें कि आरटी शेड्यूलिंग में सीमित संसाधन हैं और इसका उपयोग सावधानी से किया जाना चाहिए। n सीपीयू वाले सिस्टम में, वर्तमान आरटी थ्रेड्स की अधिकतम संख्या भी n है; यदि सभी सीपीयू अन्य आरटी थ्रेड द्वारा ले लिए जाते हैं, तो अतिरिक्त आरटी थ्रेड को प्रतीक्षा करने की आवश्यकता हो सकती है (और इस प्रकार उनकी समय सीमा छूट जाती है)।

सभी संभावित प्राथमिकता व्युत्क्रमों को हल करने के लिए, आप बाइंडर और ह्वबिंडर दोनों के लिए प्राथमिकता विरासत का उपयोग कर सकते हैं। हालाँकि, चूँकि पूरे सिस्टम में बाइंडर का व्यापक रूप से उपयोग किया जाता है, बाइंडर लेनदेन के लिए प्राथमिकता विरासत को सक्षम करने से सिस्टम सेवा की तुलना में अधिक आरटी थ्रेड्स के साथ स्पैम हो सकता है।

थ्रूपुट परीक्षण चलाएँ

थ्रूपुट परीक्षण बाइंडर/एचडब्ल्यूबाइंडर लेनदेन थ्रूपुट के विरुद्ध चलाया जाता है। ऐसी प्रणाली में जो अतिभारित नहीं है, विलंबता बुलबुले दुर्लभ हैं और उनके प्रभाव को तब तक समाप्त किया जा सकता है जब तक पुनरावृत्तियों की संख्या पर्याप्त अधिक हो।

• बाइंडर थ्रूपुट परीक्षण 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

• समय वास्तविक समय में मापी गई राउंड ट्रिप देरी को इंगित करता है।
• सीपीयू संचित समय को इंगित करता है जब सीपीयू को परीक्षण के लिए निर्धारित किया जाता है।
• Iterations परीक्षण फ़ंक्शन निष्पादित होने की संख्या को इंगित करता है।

उदाहरण के लिए, 8-बाइट पेलोड के लिए:

BM_sendVec_binderize/8         69974 ns      32700 ns      21296

... बाइंडर जो अधिकतम थ्रूपुट प्राप्त कर सकता है उसकी गणना इस प्रकार की जाती है:

8-बाइट पेलोड के साथ अधिकतम थ्रूपुट = (8 * 21296)/69974 ~= 2.423 बी/एनएस ~= 2.268 जीबी/एस

परीक्षण विकल्प

.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 में) औसत/सर्वोत्तम/सबसे खराब विलंबता और छूटी हुई समय-सीमाओं की संख्या के आंकड़े दिखाते हैं।

परीक्षण विकल्प

विलंबता परीक्षण निम्नलिखित विकल्प लेते हैं:

निम्नलिखित अनुभाग प्रत्येक विकल्प का विवरण देते हैं, उपयोग का वर्णन करते हैं और उदाहरण परिणाम प्रदान करते हैं।

पुनरावृत्तियाँ निर्दिष्ट करें

बड़ी संख्या में पुनरावृत्तियों और वर्बोज़ आउटपुट अक्षम होने वाला उदाहरण:

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.5ms) है; अधिकांश लेनदेन से इस मूल्य को पूरा करने की उम्मीद की जाती है।

"I": 10000

एक एकल परीक्षण पुनरावृत्ति में दो (2) लेनदेन शामिल हैं:

• सामान्य प्राथमिकता द्वारा एक लेनदेन ( CFS other )
• वास्तविक समय प्राथमिकता द्वारा एक लेनदेन ( RT-fifo )

5000 पुनरावृत्तियाँ कुल 10000 लेनदेन के बराबर होती हैं।

"S": 9352

9352 लेन-देन एक ही सीपीयू में समन्वयित हैं।

"R": 0.9352

उस अनुपात को इंगित करता है जिस पर क्लाइंट और सर्वर एक ही सीपीयू में एक साथ समन्वयित होते हैं।

"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 से कम हो।

युग्म मान निर्दिष्ट करें

प्रत्येक क्लाइंट प्रक्रिया को क्लाइंट के लिए समर्पित एक सर्वर प्रक्रिया के साथ जोड़ा जाता है, और प्रत्येक जोड़ी को किसी भी सीपीयू के लिए स्वतंत्र रूप से शेड्यूल किया जा सकता है। हालाँकि, लेन-देन के दौरान सीपीयू माइग्रेशन तब तक नहीं होना चाहिए जब तक कि SYNC ध्वज honor है।

सुनिश्चित करें कि सिस्टम अतिभारित न हो! जबकि एक अतिभारित प्रणाली में उच्च विलंबता अपेक्षित है, एक अतिभारित प्रणाली के लिए परीक्षण के परिणाम उपयोगी जानकारी प्रदान नहीं करते हैं। उच्च दबाव वाले सिस्टम का परीक्षण करने के लिए, -pair #cpu-1 (या सावधानी के साथ -pair #cpu ) का उपयोग करें। n > #cpu के साथ -pair n उपयोग करके परीक्षण करने से सिस्टम ओवरलोड हो जाता है और बेकार जानकारी उत्पन्न होती है।

समय सीमा मान निर्दिष्ट करें

व्यापक उपयोगकर्ता परिदृश्य परीक्षण (एक योग्य उत्पाद पर विलंबता परीक्षण चलाने) के बाद, हमने निर्धारित किया कि 2.5ms पूरा करने की समय सीमा है। उच्च आवश्यकताओं (जैसे 1000 फ़ोटो/सेकंड) वाले नए अनुप्रयोगों के लिए, यह समय सीमा मान बदल जाएगा।

वर्बोज़ आउटपुट निर्दिष्ट करें

-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

निम्नलिखित घटक विलंबता को प्रभावित कर सकते हैं:

• एंड्रॉइड बिल्ड मोड । Eng मोड आमतौर पर यूजरडीबग मोड से धीमा होता है।
• रूपरेखा । बाइंडर को कॉन्फ़िगर करने के लिए फ्रेमवर्क सेवा ioctl उपयोग कैसे करती है?
• बाइंडर ड्राइवर . क्या ड्राइवर बारीक-बारीक लॉकिंग का समर्थन करता है? क्या इसमें सभी प्रदर्शन टर्निंग पैच शामिल हैं?
• कर्नेल संस्करण . कर्नेल की वास्तविक समय क्षमता जितनी बेहतर होगी, परिणाम उतने ही बेहतर होंगे।
• कर्नेल कॉन्फिग . क्या कर्नेल कॉन्फ़िगरेशन में DEBUG_PREEMPT और DEBUG_SPIN_LOCK जैसे DEBUG कॉन्फ़िगरेशन शामिल हैं?
• कर्नेल अनुसूचक . क्या कर्नेल में एनर्जी-अवेयर शेड्यूलर (ईएएस) या हेटेरोजेनियस मल्टी-प्रोसेसिंग (एचएमपी) शेड्यूलर है? क्या कोई कर्नेल ड्राइवर ( cpu-freq ड्राइवर, cpu-idle ड्राइवर, cpu-hotplug , आदि) शेड्यूलर को प्रभावित करता है?