सिस्ट्रेस को समझना

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

systrace, Android डिवाइस की परफ़ॉर्मेंस का विश्लेषण करने का मुख्य टूल है. हालांकि, यह अन्य टूल के मामले में भी एक रैपर है. यह होस्ट-साइड रैपर है atrace के आस-पास, डिवाइस-साइड एक्ज़ीक्यूटेबल जो उपयोगकर्ता स् थान को नियंत्रित करता है ftrace को ट्रेस करने और सेट अप करने के साथ-साथ, Linux में मुख्य ट्रेसिंग तकनीक को सेट अप करना कर्नेल. systrace ऐसी ट्रेस का इस्तेमाल करता है जो ट्रेस करने की सुविधा को चालू करती है. इसके बाद, यह ftrace बफ़र को पढ़ती है और यह सब कुछ अपने-आप में मौजूद एचटीएमएल व्यूअर में रैप करता है. (हालांकि, नए कर्नेल किसी नए वर्शन के साथ काम कर सकते हैं नीचे दिए गए दस्तावेज़ में, Linux बेहतर बनाए गए बर्कले पैकेट फ़िल्टर (eBPF) के लिए, 3.18 कर्नेल (कोई eFPF नहीं) से संबंधित है, क्योंकि Pixel/Pixel पर इसी का इस्तेमाल किया गया था एक्स.)

systrace का मालिकाना हक Google Android और Google Chrome टीम के पास है और यह ओपन सोर्स के तौर पर, कैटापुल्ट प्रोजेक्ट. तय सीमा में सिसट्रेस के अलावा, गुलेल से काम आने वाली दूसरी सुविधाएं भी मिलती हैं. उदाहरण के लिए, ftrace में ज़्यादा सुविधाएं नहीं होती हैं, क्योंकि इसे सीधे तौर पर systrace या एट्रेस से चालू नहीं किया जा सकता है और इसमें कुछ ऐसी ऐडवांस सुविधाएं हैं जो परफ़ॉर्मेंस को डीबग करने के लिए ज़रूरी हैं समस्याएं. (इन सुविधाओं के लिए रूट ऐक्सेस और अक्सर एक नया कर्नेल ज़रूरी होता है.)

सिस्टम ट्रेस चलाएं

Pixel/Pixel XL पर सिग्नल में गड़बड़ी को डीबग करते समय, इन चीज़ों से शुरू करें आदेश:

./systrace.py sched freq idle am wm gfx view sync binder_driver irq workq input -b 96000

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

सिस्टम की प्रक्रिया के दौरान, ध्यान रखें कि हर इवेंट सीपीयू पर किसी चीज़ से ट्रिगर हुआ हो.

क्योंकि systrace को सीपीयू पर रन बनाने के लिए, Frace और ftrace की मदद से बनाया जाता है, CPU पर किसी चीज़ को ऐसा ftrace बफ़र लिखना होगा जो हार्डवेयर में होने वाले बदलावों को लॉग करता है. इसका मतलब है कि अगर आपको यह जानना है कि डिसप्ले फ़ेंस की स्थिति क्यों बदल गई, तो आपको यह देख सकता है कि ट्रांज़िशन के दौरान सीपीयू पर क्या चल रहा था (CPU पर चलने वाला कुछ ट्रिगर होता है, जो लॉग में बदल जाता है). यह कॉन्सेप्ट, systrace का इस्तेमाल करके परफ़ॉर्मेंस का विश्लेषण करने का आधार है.

उदाहरण: वर्किंग फ़्रेम

इस उदाहरण में, सामान्य यूज़र इंटरफ़ेस (यूआई) पाइपलाइन के लिए सिसट्रेस के बारे में बताया गया है. इसे समझने के लिए उदाहरण के साथ, ट्रेस की ज़िप फ़ाइल डाउनलोड करें (जिसमें इस सेक्शन में बताए गए अन्य ट्रेस भी शामिल हैं), तो फ़ाइल को अनज़िप करें, और systrace_tutorial.html फ़ाइल को अपने ब्राउज़र में खोलें. सावधान रहें यह सिस्टम एक बड़ी फ़ाइल है; जब तक कि रोज़ाना के कामों में इस्तेमाल न किया जा सके, काम नहीं करता है, तो शायद यह आपकी जानकारी से कहीं ज़्यादा जानकारी वाला एक बहुत बड़ा ट्रेस है इन्हें पहले कभी एक ट्रेस में नहीं देखा है.

TouchLatency, यूज़र इंटरफ़ेस (यूआई) पाइपलाइन जैसे एक जैसे और समय-समय पर होने वाले वर्कलोड के लिए में ये शामिल होते हैं:

1. SurfaceFlinger में इवेंटThread, ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) थ्रेड को चालू करता है और सिग्नल भेजता है कि यह समय है का इस्तेमाल करें.
2. यह ऐप्लिकेशन, सीपीयू और सीपीयू का इस्तेमाल करके, यूज़र इंटरफ़ेस (यूआई) थ्रेड, RenderThread, और hwuiTasks में फ़्रेम रेंडर करता है जीपीयू से जुड़े संसाधन. यह यूज़र इंटरफ़ेस (यूआई) के लिए खर्च की जाने वाली क्षमता का बड़ा हिस्सा है.
3. ऐप्लिकेशन किसी बाइंडर का इस्तेमाल करके SurfaceFlinger को रेंडर किए गए फ़्रेम को भेजता है. इसके बाद SurfaceFlinger नींद में चला जाता है.
4. SurfaceFlinger में एक दूसरा EventThread गेम ट्रिगर करने के लिए, SurfaceFlinger को जगाता है कंपोज़िशन और डिसप्ले आउटपुट. अगर SurfaceFlinger को पता चलता है कि आपकी साइट पर नहीं, यह फिर से स्लीप मोड (कम बैटरी मोड) में चला जाता है.
5. SurfaceFlinger, हार्डवेयर कंपोज़र (एचडब्ल्यूसी)/हार्डवेयर का इस्तेमाल करके कंपोज़िशन हैंडल करती है कंपोज़र 2 (एचडब्ल्यूसी2) या जीएल. एचडब्ल्यूसी/एचडब्ल्यूसी2 कंपोज़िशन वह ज़्यादा तेज़ और कम पावर करता है. हालांकि, चिप पर सिस्टम के हिसाब से इसकी सीमाएं भी तय होती हैं (SoC). आम तौर पर, इसमें ~4 से 6 मि॰से॰ लगते हैं. हालांकि, यह दूसरे चरण में भी ओवरलैप हो सकता है, क्योंकि Android ऐप्लिकेशन हमेशा तीन बार बफ़र होते हैं. (हालांकि, ऐप्लिकेशन हमेशा तीन बार बफ़र रहते हैं, लेकिन SurfaceFlinger में सिर्फ़ एक ऐसा फ़्रेम हो सकता है जिसे मंज़ूरी मिलना बाकी है. इससे वह फ़्रेम डबल बफ़रिंग के जैसा है.)
6. SurfaceFlinger, वेंडर ड्राइवर के साथ दिखाने के लिए फ़ाइनल आउटपुट भेजता है और नींद में वापस आने के लिए, EventThread के चालू होने का इंतज़ार किया जा रहा है.

चलिए, 15409 मि॰से॰ से शुरू होने वाले फ़्रेम के बारे में जानते हैं:

पहली इमेज में यह एक सामान्य फ़्रेम है जिसके चारों तरफ़ सामान्य फ़्रेम हैं, इसलिए यह यहां से आप यूज़र इंटरफ़ेस (यूआई) पाइपलाइन के काम करने का तरीका समझ सकते हैं. यूज़र इंटरफ़ेस (यूआई) की थ्रेड लाइन टचस्क्रीन के लिए, इसमें अलग-अलग समय पर अलग-अलग रंग शामिल किए जाते हैं. बार बताते हैं थ्रेड की अलग-अलग स्थितियां:

• स्लेटी. नींद आ रही है.
• ब्लू. चलाया जा सकता है (यह चल सकता है, लेकिन शेड्यूलर नहीं चल रहा ने इसे अभी तक चलाने के लिए चुना).
• हरा. सक्रिय रूप से चल रहा है (शेड्यूलर को लगता है कि यह चालू है).
• लाल. बेहिचक नींद (आम तौर पर ताले पर सोती है) कर्नेल में). यह I/O लोड का संकेत हो सकता है. डीबग करने के लिए बहुत ज़्यादा काम की है समस्याओं को ठीक करें.
• संतरा. I/O लोड के कारण बिना रुकावट वाली नींद.

बिना रुकावट के सोने की वजह जानने के लिए ( sched_blocked_reason ट्रेसपॉइंट), लाल रंग का आइकॉन चुनें स्लीप स्लाइस.

जब EventThread चल रहा हो, तो TouchLatency के लिए यूज़र इंटरफ़ेस (यूआई) थ्रेड बन जाता है रन किया जा सकता है. यह देखने के लिए कि डिवाइस की वजह से क्या रुकावट आई, नीले रंग के सेक्शन पर क्लिक करें.

दूसरी इमेज में दिखाया गया है कि TouchLatency यूज़र इंटरफ़ेस (यूआई) थ्रेड को tier 6843 से जगाया गया था, जो EventThread से मेल खाता है. यूज़र इंटरफ़ेस (यूआई) थ्रेड चालू होता है, फ़्रेम रेंडर करता है, और लाइन में लगाता है इसे SurfaceFlinger में इस्तेमाल किया जा सकेगा.

अगर किसी ट्रेस में binder_driver टैग चालू है, तो उस लेन-देन में शामिल सभी प्रोसेस की जानकारी देखने के लिए बाइंडर लेन-देन.

इमेज 4 में दिखाया गया है कि 15, 423.65 मि॰से॰ बाइंडर:6832_1 पर,SurfaceFlinger में 9579 की वजह से चलाया जा सकता है, जो TouchLatency का RenderThread होता है. आप यह भी कर सकते हैं बाइंडर ट्रांज़ैक्शन के दोनों तरफ़ क्यूबफ़र देखें.

SurfaceFlinger साइड में सूची बफ़र के दौरान, 'Google के अनुरोध' की संख्या TouchLatency के फ़्रेम 1 से 2 तक हो जाते हैं.

इमेज 5 में ट्रिपल बफ़रिंग दिखाया गया है, जहां दो प्रोसेस पूरे हो चुके हैं और ऐप्लिकेशन में तीसरे पक्ष की रेंडरिंग शुरू होने वाली है. इसकी वजह यह है कि हमने पहले ही कुछ फ़्रेम से बचने के लिए, इसलिए ऐप्लिकेशन एक फ़्रेम की जगह दो फ़्रेम सेव रखता है, ताकि और कौनसे फ़्रेम हटाए गए.

इसके तुरंत बाद, SurfaceFlinger के मुख्य थ्रेड को एक दूसरे EventThread ने चलाया था, इसलिए तो वह डिसप्ले में पुराने रुके हुए फ़्रेम का आउटपुट दे सकता है:

SurfaceFlinger में सबसे पहले, पुराने बफ़र को लॉक किया जाता है. इससे बफ़र की संख्या को दो से घटाकर एक किया जाना बाकी है.

बफ़र को लॉक करने के बाद, SurfaceFlinger कंपोज़िशन सेट अप करती है और डिसप्ले के लिए आखिरी फ़्रेम चुनें. (इनमें से कुछ सेक्शन mdss ट्रेसपॉइंट, ताकि उन्हें आपके SoC में शामिल न किया जा सके.)

इसके बाद, mdss_fb0 सीपीयू पर सक्रिय होता है 0. mdss_fb0 रेंडर किए गए फ़्रेम को डिसप्ले करने के लिए, पाइपलाइन का कर्नेल थ्रेड दिखाएं. हम ट्रेस में mdss_fb0 को उसकी लाइन के तौर पर देख सकते हैं (नीचे की ओर स्क्रोल करें व्यू).

mdss_fb0 नींद खुल जाती है, थोड़ी देर चलती है, नींद में रुकावट नहीं आती, फिर से जागता है.

उदाहरण: काम न करने वाला फ़्रेम

इस उदाहरण में ऐसे सिस्टम के बारे में बताया गया है जिसका इस्तेमाल Pixel/Pixel XL के सिग्नल को डीबग करने के लिए किया जाता है. यहां की यात्रा पर हूं उदाहरण के साथ आगे बढ़ें, zip डाउनलोड करें ट्रेस की फ़ाइल (जिसमें इस सेक्शन), तो फ़ाइल को अनज़िप करें और systrace_tutorial.html फ़ाइल को ब्राउज़र खोलें.

सिस्ट्रेस खोलने पर, आपको कुछ ऐसा दिखेगा:

जैंक खोजते समय, SurfaceFlinger में Frame डायरेक्टिव की पंक्ति देखें. FrameMeet, HW2 की बनाई हुई क्वालिटी ऑफ़ लाइफ़ को बेहतर बनाने वाला एक टूल है. देखते समय सिस्टम की मदद से, अपने डिवाइस के लिए HW2 का इस्तेमाल नहीं किया जाता. दोनों में से किसी एक में केस, फ़्रेममिस के साथ वह SurfaceFlinger में जुड़ा हुआ है जिसके पास एक बहुत ज़्यादा नियमित तौर पर इस्तेमाल होने वाले रनटाइम और ऐप्लिकेशन के लिए अधूरे बफ़र की संख्या में कोई बदलाव नहीं होता vsync पर (com.prefabulated.touchlatency).

इमेज 11 में, 15598.29&nbps;ms पर छूटे हुए फ़्रेम को दिखाया गया है. SurfaceFlinger थोड़ी देर के लिए सो गया vsync इंटरवल मिला और कोई काम किए बिना वापस सो गया. इसका मतलब है कि SurfaceFlinger को पता चला कि डिसप्ले पर फ़्रेम भेजने की कोशिश करना सही नहीं था फिर से. क्यों?

इस फ़्रेम के लिए पाइपलाइन के टूटने का तरीका समझने के लिए, पहले काम करने वाले फ़्रेम का उदाहरण ऊपर दिया है, ताकि यह देखा जा सके कि सिट्रेस में सामान्य यूज़र इंटरफ़ेस (यूआई) पाइपलाइन कैसी दिखती है. तैयार होने पर, छूटे हुए फ़्रेम पर वापस जाएं और पीछे की ओर काम करें. ध्यान दें कि SurfaceFlinger जागता है और तुरंत सो जाता है. इतने समय में TouchLatency से रुके हुए फ़्रेम, दो फ़्रेम (मदद के लिए एक अच्छा संकेत) यह पता लगाने के लिए कि क्या समस्या आ रही है).

SurfaceFlinger में फ़्रेम होने की वजह से, यह ऐप्लिकेशन से जुड़ी समस्या नहीं है. इसके अलावा, SurfaceFlinger सही समय पर चालू हो रही है. इसलिए, यह SurfaceFlinger नहीं है समस्या. अगर SurfaceFlinger और ऐप्लिकेशन, दोनों सामान्य दिखते हैं, तो हो सकता है कि यह ड्राइवर की समस्या.

mdss और sync ट्रेसपॉइंट चालू हैं. इसलिए, हमें बाड़ों के बारे में जानकारी मिल सकती है (डिसप्ले ड्राइवर और SurfaceFlinger) की मदद से, डिसप्ले में फ़्रेम सबमिट किए जाने का समय तय किया जाता है. इन बाड़ों को mdss_fb0_retire में शामिल किया गया है, जो इससे पता चलता है कि डिसप्ले पर कोई फ़्रेम कब लगा. ये बाड़ें इस तरह से दी गई हैं sync ट्रेस कैटगरी का हिस्सा है. कौनसी बाड़ें इनसे जुड़ी हैं SurfaceFlinger में कोई खास इवेंट आपके एसओसी और ड्राइवर स्टैक पर निर्भर करता है. इसलिए अपने एसओसी वेंडर के साथ मिलकर काम करें. इससे आपको फ़ेंस कैटगरी को समझने में मदद मिलेगी ट्रेस.

इमेज 13 में वह फ़्रेम दिखाया गया है जो 33 मि॰से॰ के लिए दिखाया गया है, न कि उम्मीद के मुताबिक 16.7 मि॰से॰ के लिए. उस स्लाइस से आधी दूरी पर, उस फ़्रेम को एक नए फ़्रेम से बदल दिया जाना चाहिए था लेकिन ऐसा नहीं था. पिछला फ़्रेम देखें और कुछ भी खोजें.

इमेज 14 में, 14.482 मि॰से॰ एक फ़्रेम दिखाया गया है. टूटा हुआ दो फ़्रेम वाला सेगमेंट 33.6 मि॰से॰ का था, जो करीब-करीब दो फ़्रेम के लिए उम्मीद करते हैं (हम 60 हर्ट्ज़, 16.7 मि॰से॰ पर रेंडर होते हैं) के हिसाब से फ़िल्टर करता है. हालांकि, 14.482 मि॰से॰ 16.7 मि॰से॰ के आस-पास ही नहीं है, यह सुझाव दे रही है कि डिसप्ले पाइप में कुछ गड़बड़ी है.

बाड़ कहां खत्म होता है, इसकी सटीक जांच करके तय करें कि इस बाड़ को कौन कंट्रोल करता है.

वर्कक्यू में __vsync_retire_work_handler शामिल है, जो जब आप इसे बाड़ बदल दें, तब दौड़ने में मदद मिलती है. कर्नेल सोर्स में देखकर, यह पता लगाया जा सकता है कि वह डिसप्ले ड्राइवर का हिस्सा है. इस सवाल का जवाब "ज़रूरी जानकारी" पाथ सेट अप करने के लिए किया जा सकता है, ताकि यह जल्द से जल्द चल सके. यह समय है 70 या उसके करीब के लिए चलाया जा सकता है (शेड्यूल करने में ज़्यादा समय नहीं लगता), लेकिन यह एक वर्कलाइन है और हो सकता है कि वे सही तरीके से शेड्यूल न हो पाएं.

पिछले फ़्रेम को देखकर पता लगाएं कि उसने योगदान दिया या नहीं; कभी-कभी कंपन करता है की बढ़ोतरी, समय के साथ बढ़ सकती है और इससे समयसीमा खत्म हो सकती है.

Kworker पर चलाई जा सकने वाली लाइन नहीं दिख रही है, क्योंकि व्यूअर इसे बदल देता है चुने जाने पर सफ़ेद रंग का, लेकिन आंकड़े कहानी कहते हैं: शेड्यूलर का 2.3 मि॰से॰ डिसप्ले पाइपलाइन के क्रिटिकल पाथ के कुछ हिस्से की देरी खराब है. जारी रखने से पहले, विज्ञापन के इस हिस्से को वर्कक्यू से पाइपलाइन क्रिटिकल पाथ दिखाएं (जो SCHED_OTHER सीएफ़एस थ्रेड) को खास तौर पर SCHED_FIFO के लिए kthread. इस फ़ंक्शन को टाइमिंग की गारंटी की ज़रूरत है जो वर्कक्यू नहीं कर सकते (और नहीं हैं देने के लिए न हो.

क्या जैंक की वजह यही है? यह साफ़ तौर पर कहना मुश्किल है. के बाहर आसानी से पता लगाए जा सकने वाले मामले, जैसे कि कर्नेल लॉक के विवाद की वजह से डिसप्ले अहम सोने के लिए थ्रेड करते हैं, तो ट्रेस आम तौर पर समस्या के बारे में नहीं बताते हैं. क्या फ़्रेम के गिरने की वजह यह सिग्नल नहीं हो सकता? बिल्कुल. कॉन्टेंट बनाने फ़ेंस का समय 16.7 मि॰से॰ होना चाहिए, लेकिन फ़्रेम में वे इसके करीब नहीं हैं उपयोगकर्ता को खींचकर छोड़ा गया फ़्रेम तक ले जाया जा सकता है. यह देखते हुए कि डिसप्ले पाइपलाइन कितनी अच्छी तरह से आपस में जुड़ी हुई है ऐसा हो सकता है कि फ़ेंस टाइमिंग के आस-पास वाइब्रेट करने की वजह से फ़्रेम.

इस उदाहरण में, वह समाधान जो कन्वर्ज़न में शामिल है काम की सूची से खास तौर पर बने __vsync_retire_work_handler kthread. इससे कंपन में काफ़ी सुधार हुआ और बाउंसिंग बॉल टेस्ट. बाद के ट्रेस से पता चलता है कि बाड़ किस समय के लिए है, यह बहुत पास से घूमता है 16.7 मि॰से॰ तक.