Linux पाइप की परफ़ॉर्मेंस में गिरावट

vmsplice बहुत तेज़ है

• कुछ प्रोग्राम पाइप के ज़रिए डेटा को अधिक तेज़ी से भेजने के लिए vmsplice नाम की system call का उपयोग करते हैं
• vmsplice का उपयोग न करने पर पता चला कि Linux पाइप उम्मीद से ज़्यादा धीमे हैं
• Morse code को तेज़ी से encode/decode करने वाला एक प्रोग्राम लिखा जा रहा है, और इसके लिए पाइप का उपयोग हो रहा है

आदर्श वातावरण में डेटा लिखना

• नीचे दिया गया प्रोग्राम बिना system call के डेटा कॉपी करता है
• AVX-512 का उपयोग करते हुए यह 167 GB/s की गति से चलता है
• AVX-512 को अक्षम करके AVX2 और SSE2 के साथ टेस्ट करने पर भी वही गति (167 GB/s) मिली
• जब तक vectorization का उपयोग होता है, 167 GB/s की गति हासिल की जा सकती है

वास्तव में पाइप में डेटा लिखना

• पाइप में डेटा लिखने वाला प्रोग्राम बनाकर मापने पर 17 GB/s की गति मिली
• यह buffer में लिखने की तुलना में 10 गुना धीमा है
• profiling के नतीजों से पता चला कि ज़्यादातर समय write call में खर्च होता है
• pipe_write फ़ंक्शन में memory page allocate करने में काफ़ी समय लगता है
• डेटा कॉपी करना खुद CPU समय का सिर्फ़ 20% लेता है, लेकिन फिर भी __memset_avx512_unaligned_erms से दोगुना धीमा है

vmsplice की मदद

• vmsplice user space से kernel में buffer को कॉपी किए बिना आगे बढ़ाता है
• vmsplice का उपयोग करने पर 210 GB/s की गति हासिल की जा सकती है
• vmsplice, write system call के महंगे हिस्से को bypass करता है

निष्कर्ष

• पाइप में लिखना raw memory में लिखने की तुलना में 10 गुना धीमा है
• इसकी वजह buffer को lock करने की लागत और SIMD context को save/restore करने की लागत है
• splice और vmsplice इन लागतों से बचते हैं और डेटा को अधिक कुशलता से स्थानांतरित करते हैं

GN⁺ का सार

• यह लेख vmsplice का उपयोग करके Linux पाइप की performance को अधिकतम करने का तरीका समझाता है
• vmsplice डेटा को kernel space में कॉपी किए बिना सीधे आगे बढ़ाता है, जिससे performance काफ़ी बेहतर होती है
• Morse code encoding/decoding जैसे high-speed data processing प्रोग्रामों में यह उपयोगी है
• समान क्षमता वाले दूसरे प्रोजेक्ट्स में splice और sendfile आदि शामिल हैं

[GN⁺]

Hacker News टिप्पणियाँ

• JMP को RET से प्रतिस्थापित नहीं किया जाता, इसका कारण CONFIG_RETHUNK विकल्प है

  • objdump की disassembly में देखा जा सकता है कि RET को JMP __x86_return_thunk से प्रतिस्थापित किया गया है
  • संबंधित लिंक: लिंक1, लिंक2

• फ़ंक्शन की शुरुआत और अंत में मौजूद NOP निर्देश ftrace को tracing निर्देश डालने की अनुमति देते हैं

  • यह ASM_CLAC और ASM_STAC macros से आता है
  • यदि X86_FEATURE_SMAP का पता चलता है, तो runtime में इन्हें CLAC और STAC निर्देशों से भरा जाता है
  • संबंधित लिंक: लिंक3, लिंक4, लिंक5

• एक उपयोगकर्ता का side project file descriptor के लिए ring buffer प्रदान करने वाला system call प्रस्तावित करता है

  • यदि pipe के दोनों सिरे ring buffer को support करें, तो उसी ring buffer को map करके kernel call के बिना zero-copy IO संभव हो जाता है
  • वह सहयोगियों की तलाश कर रहा है
  • संबंधित लिंक: लिंक6

• Linux pipe को "धीमा" कहना वैसा ही है जैसे Toyota Corolla को "धीमा" कहना

  • ज़्यादातर मामलों में यह पर्याप्त तेज़ है
  • जब तक मामला बहुत चरम न हो, उससे भी तेज़ कुछ खोजने की ज़रूरत नहीं है

• आधुनिक CPU पर rep movsb सबसे तेज़ vectorized version जितना तेज़ है

  • kernel function नाम "copy_user_enhanced_fast_string" इसका संकेत देता है
  • CPU features ERMS और FSRM इसे संभव बनाते हैं

• AVX512 बिजली की खपत ज़्यादा करता है और CPU frequency scaling को ट्रिगर करता है

  • संबंधित लिंक: लिंक7, लिंक8

• फिर से Hacker News का "hug of death" झेल रहा हूँ

  • cached WordPress pages की वजह से स्थिति बेहतर हुई है, लेकिन फिर भी कुछ सेकंड लगते हैं

• io_uring का उपयोग करने वाला version देखना दिलचस्प होगा

  • kernel और pre-shared buffers का उपयोग करके copy से बचा जा सकता है और system call overhead कम किया जा सकता है

• ब्लॉग के load होने में लगभग 20 सेकंड लगना अपने-आप में एक साहसी दावा है

• IPC के लगभग सभी रूप "धीमे" हैं

  • सुरक्षा के लिए performance cost चुकाने का फैसला किया गया है

• शुरू में समझ नहीं आया कि splice इतना धीमा क्यों है

  • vmsplice से धीमा होने का कारण बताया गया, लेकिन ऐसा क्यों है यह स्पष्ट नहीं है
  • ज़रूर कोई वजह होगी कि इसे vmsplice से फिर से implement नहीं किया जा सकता