12 पॉइंट द्वारा GN⁺ 2025-04-22 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • अमेरिका में डेटा सेंटरों की बिजली खपत 2023 में राष्ट्रीय बिजली का लगभग 4% थी, और 2028 तक इसके 12% तक बढ़ने का अनुमान है
  • University of Waterloo की शोध टीम ने Linux kernel के नेटवर्क प्रोसेसिंग तरीके में सुधार करके डेटा सेंटरों की बिजली खपत को अधिकतम 30% तक घटाने का तरीका विकसित किया
  • इसका मुख्य बिंदु busy polling के dynamic control में है, जो ट्रैफ़िक की स्थिति के अनुसार interrupt mode और polling के बीच अपने-आप स्विच करता है
  • यह बदलाव सिर्फ लगभग 30 पंक्तियों के कोड संशोधन से लागू किया गया, और Linux 6.13 kernel में आधिकारिक रूप से शामिल हो गया
  • Linux-आधारित डेटा सेंटरों और web server पर इसके व्यापक उपयोग की संभावना है, और यह efficiency-केंद्रित software development philosophy की वापसी पर ज़ोर देता है

डेटा सेंटर की बिजली खपत में Linux kernel कोड की सिर्फ 30 पंक्तियों से अधिकतम 30% कमी संभव

बढ़ती बिजली खपत को लेकर चिंता

  • दुनिया का अधिकांश web traffic डेटा सेंटरों के ज़रिये चलता है, और यही AI services जैसी high-power applications की बुनियाद है
  • अमेरिका में 2023 में डेटा सेंटरों ने कुल बिजली का लगभग 4% उपयोग किया, और 2028 तक यह 12% तक पहुँचने का अनुमान है

समस्या का केंद्र: Linux kernel का नेटवर्क प्रोसेसिंग तरीका

  • Linux kernel नेटवर्क packet प्रोसेस करते समय interrupt और polling दोनों तरीकों का इस्तेमाल करता है
    • interrupt: नया packet आने पर CPU अपना मौजूदा काम रोककर उसे प्रोसेस करता है
    • busy polling: latency घटाने के लिए packet हो या न हो, सिस्टम समय-समय पर जाँच करता रहता है → अक्षम

समाधान: busy polling को dynamic तरीके से स्विच करना

  • University of Waterloo के Professor Martin Karsten की टीम ने network traffic के अनुसार
    • ट्रैफ़िक ज़्यादा होने पर: busy polling का उपयोग
    • ट्रैफ़िक कम होने पर: interrupt mode में स्विच
  • इससे अनावश्यक बिजली खपत घटती है और लचीलापन बढ़ता है

कोड संशोधन और लागू होने की स्थिति

  • Fastly के engineer Joe Damato के साथ मिलकर इसे मौजूदा kernel code को पुनर्व्यवस्थित करने के तरीके से लागू किया गया
  • नया कोड लिखे बिना, मौजूदा संरचना बदलकर लगभग 30 पंक्तियों का संशोधन किया गया
  • Linux 6.13 kernel (जनवरी 2025 रिलीज़) में इसे आधिकारिक रूप से शामिल किया गया
    kernel commit

ऊर्जा बचत का प्रभाव

  • network-केंद्रित applications में अधिकतम 30% बिजली बचत
    • सामान्य applications में यह बचत दर इससे कम हो सकती है
  • ट्रैफ़िक बदलाव के अनुसार अपने-आप अनुकूलन होने से यह डेटा सेंटरों के लिए उपयुक्त है
  • Linux-आधारित web server (nginx, Apache आदि) तक भी इसका विस्तार संभव है

कम्युनिटी में प्रसार और open source पर प्रभाव

  • Damato इस तकनीक को Fastly के H2O server में भी लागू करने की योजना बना रहे हैं
  • kernel code open source होने के कारण, अन्य web server developers भी इससे संदर्भ ले सकते हैं
  • ऊर्जा दक्षता-केंद्रित development culture की बहाली के लिए इसके उत्प्रेरक बनने की उम्मीद है

शोध का दार्शनिक महत्व

  • “90 के दशक में resource optimization computer science की बुनियाद था”, लेकिन पिछले 20 वर्षों में performance-केंद्रित रुझान के कारण efficiency की अनदेखी हुई
  • यह शोध दिखाता है कि “कोड में छोटा सुधार भी बहुत बड़ी ऊर्जा बचत में बदल सकता है”, और sustainable software development की दिशा सुझाता है

2 टिप्पणियां

 
GN⁺ 2025-04-22
Hacker News राय
  • Linux ने high-performance networking के लिए busy polling feature जोड़ा है। ज़्यादातर Linux software इसका इस्तेमाल नहीं करते, लेकिन datacenter में इस्तेमाल होने वाले software के लिए यह तब ऊर्जा-अक्षम होता है जब system व्यस्त नहीं होता। यह patch system के व्यस्त न होने पर इसे बंद करके energy efficiency बहाल करने देता है।

    • लेख का शीर्षक थोड़ा भ्रामक है। इससे लगता है कि यह desktop workloads पर भी लागू होगा, लेकिन वास्तव में यह datacenter के लिए है। अगर शीर्षक में "in datacenters" जोड़ा गया होता, तो भ्रम से बचा जा सकता था।
  • high-performance datacenter workloads का बड़ा हिस्सा वास्तव में Linux kernel के network stack से होकर नहीं जाता।

    • इसके बजाय DPDK, XDP, या Onload और VMA जैसे user-space stacks इस्तेमाल किए जाते हैं। अक्सर SmartNICs hardware offload करते हैं। ऐसे मामलों में यह patch लागू नहीं होता।
    • लेकिन यह patch उन setups में निश्चित रूप से मदद करता है जहाँ kernel data path में होता है, जैसे CDNs, ingress nodes, VM, embedded Linux systems आदि। जिन workloads में performance या latency कारणों से पहले ही kernel को bypass किया जा रहा है, उन पर इसका बड़ा असर नहीं होगा। 30% power savings वाली headline बहुत हद तक context पर निर्भर करेगी।
  • इस बदलाव के बारे में अधिक जानकारी https://lwn.net/Articles/1008399/ पर देखी जा सकती है।

  • यह वास्तव में शानदार बदलाव है। एक high-performance computing विशेषज्ञ के रूप में, मैं अक्सर सोचता हूँ कि inefficient code की वजह से कितनी ऊर्जा बर्बाद होती है, और जैसे-जैसे planetary computing scale होती है, यह कितना बड़ा मुद्दा बनता जाएगा।

    • व्यक्तिगत रूप से, मुझे लगता है कि code को यथासंभव efficient होना एक नैतिक जिम्मेदारी है। खासकर तब, जब कोई workload सैकड़ों CPU पर महीनों तक चलता हो।
  • इसके उलट, Meta के पास GPU को व्यस्त बनाए रखने का एक hack है ताकि LLM training के दौरान power consumption अधिक stable रहे। उदाहरण के लिए, batch synchronization के समय वे power में बड़ा drop नहीं चाहते।

  • क्या इसका मतलब है कि kernel में "adaptive interrupt moderation" अब इस्तेमाल नहीं होता? मैंने करीब 15 साल से इस क्षेत्र में काम नहीं किया है, लेकिन कम network speed पर interrupts का उपयोग और एक निश्चित बिंदु के बाद interrupts बंद करके polling का उपयोग करने वाला adaptive kernel व्यवहार हुआ करता था।

    • जिस समस्या को हल करने की कोशिश थी, वह थी traffic में अचानक और नाटकीय बदलाव। उदाहरण के लिए, switching में loop आ जाना और उससे जुड़ा packet storm पैदा होना। ऐसी स्थिति में interrupts इतनी तेज़ी से आते थे कि system को interrupts disable करने लायक non-interrupt समय ही नहीं मिल पाता था। इसलिए समाधान यह था कि Linux routers में network interfaces से अधिक cores हों।
  • जब किसी वाक्य में "Up To" शामिल हो, तो शब्दशः कुछ भी संभव होता है।

  • विषय से हटकर, लेकिन Joe Damato के बारे में फिर से पढ़कर खुशी हुई। पुरानी यादें ताज़ा हो गईं। पहले James Gollick का tcmalloc पर लेख पढ़ा, फिर packagecloud.io के बारे में जाना, और उसके बाद Joe के शानदार लेखों से परिचय हुआ।

  • मुख्य अनुच्छेद:

    • "इस energy saving के साथ एक caveat है। '30% network stack या communication हिस्से पर लागू होने वाला best-case है,' Karsten ने समझाया। 'अगर application मुख्य रूप से वही करता है, तो 30% improvement दिख सकती है। अगर application बहुत से दूसरे काम करता है और कभी-कभी network का उपयोग करता है, तो 30% घटकर काफी कम मूल्य रह जाएगा.'"
  • इस लेख ने पुरानी यादें ताज़ा कर दीं : https://didgets.substack.com/p/finding-and-fixing-a-billion-bug

 
semanticist 27 일 전

ओ~ दिलचस्प है।
यह सोचने पर भी मजबूर करता है कि परफेक्ट software जैसी चीज़ शायद अब भी नहीं है।