Android में 16KB page size जोड़ा गया

 (android-developers.googleblog.com)
10 पॉइंट द्वारा GN⁺ 2024-08-24 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • पेज वह न्यूनतम इकाई है जिसके आधार पर operating system memory को manage करता है
  • अधिकांश CPU 4 KB page size को support करते हैं, और Android OS व applications 4 KB page size के लिए optimized रहे हैं
  • ARM CPU 16 KB page size को support करते हैं, और जब Android इस size का उपयोग करता है तो performance 5-10% बेहतर होती है, जबकि memory usage लगभग 9% बढ़ जाता है
  • overall operating system performance को बेहतर बनाने और device manufacturers को यह trade-off चुनने देने के लिए Android 15 को 4 KB या 16 KB page size के साथ चलाया जा सकता है
  • 16 KB page size को support करने वाला पहला Android system कुछ devices में developer option के रूप में उपलब्ध कराया जाएगा

16KB page size के तकनीकी विवरण

  • अधिकांश CPU में Memory Management Unit (MMU) नाम का dedicated hardware होता है, जो program द्वारा उपयोग किए जा रहे addresses को memory के physical locations में translate करता है
  • यह translation page size की इकाइयों में किया जाता है
    • हर बार जब program को अधिक memory चाहिए होती है, operating system को बीच में आकर "page table" entries भरनी पड़ती हैं और उस memory chunk को process को allocate करना पड़ता है
  • यदि page size 4 गुना बड़ा हो जाए, तो bookkeeping का काम 4 गुना कम हो जाता है
    • इसलिए system low-level operating system paperwork में कम समय खर्च कर सकता है और video को अच्छा दिखाने, games को बेहतर चलाने, और apps को smooth रूप से run कराने में अधिक समय दे सकता है
  • page size, Application Binary Interface (ABI) नहीं है
  • यानी अगर application को page size से स्वतंत्र बनाया जाए, तो वही application binary 4KB और 16KB दोनों devices पर चल सकती है
  • Android 15 में Android को शुरू से refactor किया गया है ताकि वह अलग-अलग page sizes पर चल सके और page size पर निर्भर न रहे

मुख्य OS बदलाव

  • Android 15 आधारित devices:
    • compile-time PAGE_SIZE macro को runtime getpagesize(2) से replace किया गया है
    • सभी OS binaries को 16 KB aligned किया गया है (third-party applications/libraries 16KB aligned न भी हों)
    • सभी OS binaries को अलग loadable segments के रूप में build किया गया है ताकि process में mapped सभी memory areas को पढ़ा जा सके; कुछ applications इसी पर निर्भर करती हैं
    • कई OS components को दोबारा लिखा गया है ताकि वे page size को assume न करें और बड़े page sizes के लिए optimized हों

file system

  • अच्छी performance के लिए file system block size का page size से match करना ज़रूरी है. EROFS और F2FS file systems तथा UFS storage layer 16KB compatible हैं
  • 4KB systems में 16KB alignment के लिए जोड़ा गया अतिरिक्त padding ELF executables के size को बढ़ाता है, लेकिन कई optimizations के ज़रिए इस cost से बचा गया है
  • sparse read-only file system यह सुनिश्चित करता है कि 16KB alignment के लिए बने अतिरिक्त padding की generated 0 pages disk पर write न हों
  • read/write file systems 0 pages को case-by-case basis पर handle करते हैं

memory management

  • Linux page cache में बदलाव किया गया है ताकि वह इस अतिरिक्त padding space के लिए prefetch न करे, जिससे अनावश्यक memory load से बचत होती है
  • यह page खाली padding होता है और program इसे कभी नहीं पढ़ता. यह केवल alignment के लिए program के usable हिस्सों के बीच की जगह है

Linux kernel

  • Linux kernel किसी विशेष page size से गहराई से जुड़ा होता है, इसलिए kernel build करते समय उपयोग होने वाला page size चुनना पड़ता है, जबकि operating system का बाकी हिस्सा समान रहता है

Android applications

  • जिन applications में native code या dependencies हैं, उन्हें 16KB page size devices के साथ compatible बनाने के लिए फिर से compile करना होगा
  • क्योंकि अधिकांश Android applications और SDKs के भीतर का native code 4KB page size को ध्यान में रखकर build किया गया था, इसलिए उसे 16KB के लिए फिर से align करना होगा ताकि binaries 4KB और 16KB दोनों devices के साथ compatible हों
  • अधिकांश applications और SDKs के लिए यह 2-step process है:
    1. native code को 16KB alignment के साथ rebuild करें
    2. अगर page size के बारे में hardcoded assumptions हैं, तो 16KB device/emulator पर test करके उन्हें ठीक करें

16 KB devices के लिए development

  • अभी production में मौजूद Android devices 16 KB page size को support नहीं करते
    • इसे हल करने के लिए partners के साथ काम किया जा रहा है ताकि मौजूदा devices पर developer option उपलब्ध कराया जा सके
  • developer option के रूप में 16 KB page size support दिया जाएगा
  • Android Studio में 16 KB emulator target उपलब्ध है

16 KB developer option

  • Android 15 में 16 KB और 4 KB page sizes के बीच switch करने के लिए developer option लागू किया गया है
  • यह Pixel 8 और Pixel 8 Pro पर उपलब्ध है, और आगे और devices में support आने वाला है
  • developer option का उपयोग करने के लिए device को reset करना और bootloader unlock करना होगा

x86_64 desktop पर 16 KB

  • x86_64 emulator में 16 KB page size को emulate किया जा सकता है
  • Android Studio SDK Manager से 16 KB page emulator को download और run किया जा सकता है

भविष्य

  • Android 15 और AOSP 16 KB pages को support करते हैं, और इसे developer option के रूप में लागू किया जा सकता है
  • उम्मीद है कि application और SDK developers इस option का उपयोग करके अधिक performant और efficient Android devices के लिए तैयारी कर सकेंगे

GN⁺ की राय

  • 16KB page size की ओर बदलाव Android devices की performance और efficiency बढ़ाने के लिए एक महत्वपूर्ण परिवर्तन है
  • बड़े page size का उपयोग करने से memory management overhead कम हो सकता है और overall system performance बेहतर हो सकती है
  • हालांकि, यह बदलाव compatibility issues भी ला सकता है, खासकर उन apps और SDKs के लिए जो native code पर निर्भर हैं, इसलिए developers को 16KB page size को ध्यान में रखकर अपने software को update करना चाहिए
  • Google, 16KB developer option और emulator support के ज़रिए developers को इस transition की testing और तैयारी के लिए tools दे रहा है
  • 16KB pages फिलहाल केवल ARM-आधारित Android devices पर लागू हैं, लेकिन भविष्य में इनके दूसरे hardware platforms तक बढ़ने की संभावना है
  • developers को apps और SDKs को 16KB page size के अनुसार ढालने के अलावा, बड़े page size के memory usage पर पड़ने वाले प्रभाव को भी ध्यान में रखना चाहिए और ज़रूरत पड़ने पर memory optimization करना चाहिए
  • 16KB pages की ओर यह बदलाव Android ecosystem भर में सहयोग मांगने वाला एक महत्वपूर्ण प्रयास है, लेकिन अंततः यह users को बेहतर performance और efficiency देगा

संबंधित पढ़ाई

2 टिप्पणियां

 
GN⁺ 2024-08-24
Hacker News राय

  • Debian kernel में ARM64 kernel को 16KiB page size के साथ build करने का काम हाल ही में शुरू हुआ है

    • 64KiB page size जोड़ने पर भी चर्चा चल रही है
    • Apple M1 का DART IOMMU कम-से-कम 16KiB page size मांगता है, इसलिए efficiency बढ़ने की उम्मीद है

  • पहला 16KB support वाला Android system कुछ devices पर developer option के रूप में उपलब्ध कराया जाएगा

    • developer option के जरिए test और fix करना संभव है
    • page-size-agnostic application binaries 4KB और 16KB devices दोनों पर चल सकती हैं

  • यह जानने की जिज्ञासा है कि application कब page-size-agnostic नहीं होती

    • किस स्थिति में यह समस्या आती है, यह जानना चाहेंगे

  • 4KB और 16KB process को एक साथ support किए बिना 16KB default इस्तेमाल करना समस्याजनक है

    • पुराने binaries टूट सकते हैं और emulator performance गिरने की आशंका है
    • 4KB pages को भी support करने वाला kernel चाहिए
    • CPU design में 16KB page table entries को 4KB units में map करने की सुविधा होना तर्कसंगत होगा

  • iOS 64-bit transition के बाद से 16KB pages इस्तेमाल करता आया है

    • ARM Mac ने भी यही design अपनाया है

  • RHEL ने पहले AARCH64 पर 64KB pages आज़माए थे, लेकिन कई bugs के कारण आखिरकार उसे वापस लेना पड़ा

    • Google की कोशिश प्रभावशाली है, लेकिन यह सफल होगी या नहीं, इस पर संदेह है

  • यह जानने की जिज्ञासा है कि 16KB pages को enable करने वाले kernel और ecosystem work में Asahi ने कितनी मदद की

    • RISC-V का 4KB pages पर fixed रहना एक गलती जैसा लगता है

  • iOS बहुत पहले से 16K pages इस्तेमाल करता आया है

    • OSX ने M1 के साथ 2020 में 16K pages पर switch किया
    • Windows AArch64 पर भी 4K pages पर ही टिका हुआ है
    • Linux कई तरह के page sizes support करता है. Asahi 16K इस्तेमाल करता है

  • यह जानने की जिज्ञासा है कि page size बढ़ने से I/O performance या flash lifespan पर नकारात्मक असर पड़ता है या नहीं

    • यह भी जानना चाहेंगे कि आधुनिक managed flash devices की write unit 4KB या 16KB से बड़ी होती है या नहीं

  • performance improvement मापा गया है

    • खासकर camera app तेज़ी से शुरू होती है
    • दूसरी optimization संभावनाओं के बारे में जिज्ञासा है
    • यह भी जानना चाहेंगे कि क्या Lisp के "image dump" जैसी किसी विधि से initialization code को न्यूनतम किया जा सकता है

  • 5-10% performance improvement बड़ा आंकड़ा लगता है

    • अगर page walk इतना महंगा है, तो क्या बड़ा TLB नहीं होना चाहिए, इस पर सवाल है
    • memory usage में 9% बढ़ोतरी भी बड़ी लगती है
    • memory usage पर पड़े प्रभाव के बारे में जिज्ञासा है
 
gurugio 2024-08-30
  • नवीन storage में IO अक्सर storage के अंदरूनी cache में सेव हो जाता है, इसलिए 16KB में IO होने पर भी शायद कोई खास फर्क नहीं पड़ेगा।
  • Camera, GPU जैसी performance-critical डिवाइसों को लगातार pages allot होने पर उनकी performance बेहतर होती है.
  • TLB hardware cache है, इसलिए लागत एक समस्या हो सकती है।
  • Memory usage 10% बढ़ना, हाल के मॉडलों की memory capacity को देखते हुए, बहुत बड़ी समस्या नहीं माना जा रहा है।
  • 4k/16k को एक साथ support करने के लिए CPU core से लेकर kernel core हिस्से तक बदलाव करने पड़ेंगे, इसलिए मुझे यह लगभग असंभव लगता है। Kernel ने hugepage जैसी बड़ी page functionality का लंबे समय से इस्तेमाल किया है, इसलिए 16k operation अपने आप में बड़ी समस्या नहीं होगी। Kernel के बाहर Android की features या apps में जो समस्याएँ आएँगी, उन्हें Google को संभालना होगा।
  • वैसे भी 64-bit cores और लगातार बढ़ती memory के दौर में page size बढ़ाने की बात server market में पहले से होती रही है। अब smartphone में भी इसे अनिवार्य रूप से लागू करना पड़ेगा।