Android की परफ़ॉर्मेंस को बेहतर बनाना: कर्नेल के लिए AutoFDO लॉन्च करना

हम Android LLVM टूलचेन टीम हैं. हमारी सबसे बड़ी प्राथमिकताओं में से एक है, LLVM इकोसिस्टम में ऑप्टिमाइज़ेशन की तकनीकों की मदद से Android की परफ़ॉर्मेंस को बेहतर बनाना. हम लगातार ऐसे तरीके ढूंढ रहे हैं जिनसे Android को ज़्यादा तेज़, बेहतर, और असरदार बनाया जा सके. हालांकि, ऑप्टिमाइज़ेशन से जुड़ा हमारा ज़्यादातर काम यूज़रस्पेस में होता है, लेकिन कर्नेल, सिस्टम का अहम हिस्सा बना रहता है. आज हमें यह बताते हुए खुशी हो रही है कि हम Android कर्नेल में, फ़ीडबैक के आधार पर अपने-आप ऑप्टिमाइज़ होने वाली सुविधा (AutoFDO) को कैसे जोड़ रहे हैं, ताकि उपयोगकर्ताओं को बेहतर परफ़ॉर्मेंस मिल सके.

AutoFDO क्या है?

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

AutoFDO, असल में इस्तेमाल के पैटर्न का इस्तेमाल करके कंपाइलर को गाइड करता है. इससे इस समस्या को हल किया जा सकता है. इन पैटर्न से, निर्देश के एक्ज़ीक्यूशन के उन पाथ के बारे में पता चलता है जिनका इस्तेमाल कोड, असल में इस्तेमाल के दौरान करता है. ये पैटर्न, सीपीयू की ब्रांचिंग के इतिहास को रिकॉर्ड करके कैप्चर किए जाते हैं. हालांकि, यह डेटा फ़्लीट डिवाइसों से इकट्ठा किया जा सकता है, लेकिन कर्नेल के लिए हम इसे लैब के एनवायरमेंट में सिंथेसाइज़ करते हैं. इसके लिए, हम प्रतिनिधि वर्कलोड का इस्तेमाल करते हैं. जैसे, सबसे ज़्यादा लोकप्रिय 100 ऐप्लिकेशन चलाना. हम इस डेटा को कैप्चर करने के लिए, सैंपलिंग प्रोफ़ाइलर का इस्तेमाल करते हैं. इससे हमें यह पता चलता है कि कोड के कौनसे हिस्से 'हॉट' (बार-बार इस्तेमाल किए जाने वाले) हैं और कौनसे 'कोल्ड' हैं.जब हम इन प्रोफ़ाइलों की मदद से कर्नेल को फिर से बनाते हैं, तो कंपाइलर, Android के असल वर्कलोड के हिसाब से, ऑप्टिमाइज़ेशन के बेहतर फ़ैसले ले सकता है.

इस ऑप्टिमाइज़ेशन के असर को समझने के लिए, इन अहम तथ्यों पर ध्यान दें:

• Android में, कर्नेल, सीपीयू के समय का करीब 40% हिस्सा लेता है.
• हम यूज़रस्पेस में, नेटिव एक्ज़ीक्यूटेबल और लाइब्रेरी को ऑप्टिमाइज़ करने के लिए, पहले से ही AutoFDO का इस्तेमाल कर रहे हैं. इससे, कोल्ड ऐप्लिकेशन लॉन्च होने में करीब 4% की बढ़ोतरी हुई है और बूट होने में लगने वाला समय 1% कम हुआ है.

असल में इस्तेमाल के दौरान परफ़ॉर्मेंस में बढ़ोतरी

हमने कंट्रोल किए गए लैब के एनवायरमेंट से मिली प्रोफ़ाइलों का इस्तेमाल करके, Android की अहम मेट्रिक में शानदार सुधार देखे हैं. ये प्रोफ़ाइलें, ऐप्लिकेशन क्रॉल करने और लॉन्च करने के दौरान इकट्ठा की गई थीं. इन्हें Pixel डिवाइसों पर, 6.1, 6.6, और 6.12 कर्नेल पर मेज़र किया गया था.

सबसे अहम सुधार यहां दिए गए हैं. इन कर्नेल वर्शन के लिए, AutoFDO प्रोफ़ाइलों के बारे में ज़्यादा जानकारी, android16-6.12 और android15-6.6 कर्नेल के लिए, Android कर्नेल के संबंधित रिपॉज़िटरी में देखी जा सकती है.

ये सिर्फ़ थ्योरेटिकल आंकड़े नहीं हैं. इनसे, असली उपयोगकर्ता को ज़्यादा तेज़ इंटरफ़ेस, ऐप्लिकेशन के बीच तेज़ी से स्विच करने की सुविधा, बैटरी लाइफ़ में बढ़ोतरी, और कुल मिलाकर ज़्यादा रिस्पॉन्सिव डिवाइस मिलता है.

यह कैसे काम करता है: पाइपलाइन

हमारी डिप्लॉयमेंट की रणनीति में, एक सोफ़िस्टिकेटेड पाइपलाइन शामिल है. इससे यह पक्का किया जाता है कि प्रोफ़ाइलें काम की बनी रहें और परफ़ॉर्मेंस स्थिर रहे.

पहला चरण: प्रोफ़ाइल कलेक्शन

यूज़रस्पेस बाइनरी की प्रोफ़ाइल बनाने के लिए, हम अपने इंटरनल टेस्ट फ़्लीट पर निर्भर रहते हैं. हालांकि, हमने जेनेरिक कर्नेल इमेज (जीकेआई) के लिए, कंट्रोल किए गए लैब के एनवायरमेंट का इस्तेमाल करना शुरू कर दिया है. डिवाइस के रिलीज़ साइकल से प्रोफ़ाइलिंग को अलग करने से, डिप्लॉय किए गए कर्नेल वर्शन से अलग, तुरंत और आसानी से अपडेट किए जा सकते हैं. अहम बात यह है कि टेस्ट से पुष्टि होती है कि लैब में इकट्ठा किए गए डेटा से, असल में इस्तेमाल के दौरान फ़्लीट से मिले डेटा के मुकाबले, परफ़ॉर्मेंस में बढ़ोतरी होती है.

• टूल और एनवायरमेंट: हम टेस्ट डिवाइसों को कर्नेल की नई इमेज के साथ फ़्लैश करते हैं. साथ ही, निर्देश के एक्ज़ीक्यूशन की स्ट्रीम को कैप्चर करने के लिए, simpleperf का इस्तेमाल करते हैं. इस प्रोसेस में, ब्रांचिंग के इतिहास को रिकॉर्ड करने के लिए, हार्डवेयर की क्षमताओं का इस्तेमाल किया जाता है. खास तौर पर, Pixel डिवाइसों पर  ARM Embedded Trace Extension (ETE) और ARM Trace Buffer Extension (TRBE) का इस्तेमाल किया जाता है.
• वर्कलोड: हम Android ऐप्लिकेशन की कंपैटिबिलिटी टेस्ट सुइट (सी-सूट) से, सबसे ज़्यादा लोकप्रिय 100 ऐप्लिकेशन का इस्तेमाल करके, प्रतिनिधि वर्कलोड बनाते हैं. सबसे सटीक डेटा कैप्चर करने के लिए, हम इन पर फ़ोकस करते हैं:
  • ऐप्लिकेशन लॉन्च करना: उपयोगकर्ता को होने वाली सबसे ज़्यादा देरी के लिए ऑप्टिमाइज़ करना
  • एआई-ड्रिवन ऐप्लिकेशन क्रॉल करना: लगातार, उपयोगकर्ता के इंटरैक्शन को सिम्युलेट करना
  • सिस्टम-वाइड मॉनिटरिंग: सिर्फ़ फ़ोरग्राउंड ऐप्लिकेशन की गतिविधियों को ही नहीं, बल्कि अहम बैकग्राउंड वर्कलोड और इंटर-प्रोसेस कम्यूनिकेशन को भी कैप्चर करना
• पुष्टि करना: सिंथेसाइज़ किए गए इस वर्कलोड में, हमारे इंटरनल फ़्लीट से इकट्ठा किए गए एक्ज़ीक्यूशन पैटर्न से 85% समानता दिखती है.
• टारगेट किया गया डेटा: इन टेस्ट को बार-बार करके, हम हाई-फ़िडेलिटी एक्ज़ीक्यूशन पैटर्न कैप्चर करते हैं. इनसे, सबसे ज़्यादा लोकप्रिय ऐप्लिकेशन के साथ, असल में उपयोगकर्ता के इंटरैक्शन का सटीक अनुमान लगाया जा सकता है. इसके अलावा, इस एक्सटेंसिबल फ़्रेमवर्क की मदद से, हम अपने कवरेज को बढ़ाने के लिए, अतिरिक्त वर्कलोड और बेंचमार्क को आसानी से इंटिग्रेट कर सकते हैं.

दूसरा चरण: प्रोफ़ाइल प्रोसेसिंग

हम रॉ ट्रेस डेटा को पोस्ट-प्रोसेस करते हैं, ताकि यह साफ़, असरदार, और कंपाइलर के लिए तैयार हो.

• एग्रीगेशन: हम कई टेस्ट रन और डिवाइसों से मिले डेटा को, एक ही सिस्टम व्यू में कंसोलिडेट करते हैं.
• कन्वर्ज़न: हम रॉ ट्रेस को AutoFDO प्रोफ़ाइल फ़ॉर्मैट में बदलते हैं. साथ ही, ज़रूरत के हिसाब से, काम के न होने वाले सिंबल को फ़िल्टर करते हैं.
• प्रोफ़ाइल ट्रिम करना: हम प्रोफ़ाइलों को ट्रिम करके, "कोल्ड" फ़ंक्शन के लिए डेटा हटाते हैं. इससे, वे स्टैंडर्ड ऑप्टिमाइज़ेशन का इस्तेमाल कर पाते हैं. इससे, कभी-कभी इस्तेमाल किए जाने वाले कोड में रिग्रेशन नहीं होता और बाइनरी साइज़ में गैर-ज़रूरी बढ़ोतरी नहीं होती.

तीसरा चरण: प्रोफ़ाइल टेस्टिंग

डिप्लॉयमेंट से पहले, प्रोफ़ाइलों की कड़ी जांच की जाती है, ताकि यह पक्का किया जा सके कि वे स्थिरता से जुड़े जोखिमों के बिना, लगातार बेहतर परफ़ॉर्मेंस दें.

• प्रोफ़ाइल और बाइनरी का विश्लेषण: हम नई प्रोफ़ाइल के कॉन्टेंट (इसमें हॉट फ़ंक्शन, सैंपल की संख्या, और प्रोफ़ाइल का साइज़ शामिल है) की तुलना, पहले के वर्शन से करते हैं. हम नई कर्नेल इमेज बनाने के लिए, प्रोफ़ाइल का इस्तेमाल भी करते हैं. साथ ही, बाइनरी का विश्लेषण करके यह पक्का करते हैं कि टेक्स्ट सेक्शन में किए गए बदलाव, उम्मीद के मुताबिक हों.
• परफ़ॉर्मेंस की पुष्टि करना: हम कर्नेल की नई इमेज पर, टारगेट किए गए बेंचमार्क चलाते हैं. इससे पुष्टि होती है कि यह, पहले के बेसलाइन से तय की गई परफ़ॉर्मेंस में सुधार को बनाए रखता है.

लगातार अपडेट

समय के साथ, कोड में स्वाभाविक रूप से "बदलाव" होते हैं. इसलिए, स्टैटिक प्रोफ़ाइल की असरदारता धीरे-धीरे कम हो जाती है. बेहतर परफ़ॉर्मेंस बनाए रखने के लिए, हम नियमित अपडेट देने के लिए, पाइपलाइन को लगातार चलाते हैं:

• नियमित रीफ़्रेश: हम हर जीकेआई रिलीज़ से पहले, Android कर्नेल की एलटीएस ब्रांच में प्रोफ़ाइलों को रीफ़्रेश करते हैं. इससे यह पक्का होता है कि हर बिल्ड में, प्रोफ़ाइल का नया डेटा शामिल हो.
• आने वाले समय में विस्तार: फ़िलहाल, हम ये अपडेट android16-6.12 और android15-6.6 ब्रांच के लिए उपलब्ध करा रहे हैं. साथ ही, हम आने वाले समय में, जीकेआई के नए वर्शन के लिए भी इन्हें उपलब्ध कराएंगे. जैसे, आने वाला android17-6.18.

स्थिरता पक्का करना

प्रोफ़ाइल-गाइडेड ऑप्टिमाइज़ेशन के बारे में अक्सर यह सवाल पूछा जाता है कि क्या इससे स्थिरता से जुड़े जोखिम पैदा होते हैं. AutoFDO, सोर्स कोड की लॉजिक में बदलाव करने के बजाय, मुख्य रूप से कंपाइलर के ह्यूरिस्टिक (अनुभव के आधार पर समस्या हल करने की तकनीक) को प्रभावित करता है. जैसे, फ़ंक्शन इनलाइन करना और कोड लेआउट. इसलिए, यह कर्नेल की फ़ंक्शनल इंटिग्रिटी को बनाए रखता है. इस टेक्नोलॉजी को बड़े पैमाने पर पहले ही आज़माया जा चुका है. यह सालों से, Android प्लैटफ़ॉर्म लाइब्रेरी, ChromeOS, और Google के अपने सर्वर इन्फ़्रास्ट्रक्चर के लिए, स्टैंडर्ड ऑप्टिमाइज़ेशन के तौर पर काम कर रही है.

लगातार बेहतर परफ़ॉर्मेंस की गारंटी देने के लिए, हम "डिफ़ॉल्ट रूप से कंज़र्वेटिव" रणनीति अपनाते हैं. हमारी हाई-फ़िडेलिटी प्रोफ़ाइलों में कैप्चर नहीं किए गए फ़ंक्शन को, कंपाइलर के स्टैंडर्ड तरीकों का इस्तेमाल करके ऑप्टिमाइज़ किया जाता है. इससे यह पक्का होता है कि कर्नेल के "कोल्ड" या कभी-कभी इस्तेमाल किए जाने वाले हिस्से, स्टैंडर्ड बिल्ड की तरह ही काम करें. साथ ही, कॉर्नर केस में परफ़ॉर्मेंस रिग्रेशन या उम्मीद के मुताबिक न होने वाली गतिविधियां न हों.

आगे की योजना

फ़िलहाल, हम android16-6.12 और android15-6.6 ब्रांच के लिए, AutoFDO को डिप्लॉय कर रहे हैं. शुरुआती रोल आउट के अलावा, हमें इस टेक्नोलॉजी को और बेहतर बनाने के लिए, कई बेहतरीन अवसर दिख रहे हैं:

• ज़्यादा लोगों तक पहुंच: हम आने वाले समय में, जीकेआई कर्नेल के नए वर्शन और मौजूदा aarch64 के अलावा, अन्य बिल्ड टारगेट के लिए, AutoFDO प्रोफ़ाइलें डिप्लॉय करना चाहते हैं.
• जीकेआई मॉड्यूल ऑप्टिमाइज़ेशन: फ़िलहाल, हमारा ऑप्टिमाइज़ेशन, कर्नेल की मुख्य बाइनरी (vmlinux) पर फ़ोकस है. जीकेआई मॉड्यूल के लिए, AutoFDO को बढ़ाने से, कर्नेल सबसिस्टम के ज़्यादा हिस्से को परफ़ॉर्मेंस के फ़ायदे मिल सकते हैं.
• वेंडर मॉड्यूल के लिए सहायता: हम ड्राइवर डेवलपमेंट किट (डीडीके) का इस्तेमाल करके बनाए गए वेंडर मॉड्यूल के लिए, AutoFDO की सहायता भी उपलब्ध कराना चाहते हैं. हमारे बिल्ड सिस्टम (Kleaf) और प्रोफ़ाइलिंग टूल (simpleperf) में, सहायता पहले से ही उपलब्ध है. इससे वेंडर, अपने खास हार्डवेयर ड्राइवर पर, ऑप्टिमाइज़ेशन की इन तकनीकों को लागू कर सकते हैं.
• प्रोफ़ाइल का ज़्यादा कवरेज: क्रिटिकल यूज़र जर्नी (सीयूजे) की ज़्यादा रेंज से प्रोफ़ाइलें इकट्ठा करके, उन्हें ऑप्टिमाइज़ किया जा सकता है.

Android कर्नेल के लिए, AutoFDO को लॉन्च करके, हम यह पक्का कर रहे हैं कि ओएस की बुनियादी चीज़ें, आपके डिवाइस को हर दिन इस्तेमाल करने के तरीके के हिसाब से ऑप्टिमाइज़ हों.