एक ब्रांच जो बताती है कि उसे किसने लिखा
पिछले सप्ताहांत लिनस टोरवाल्ड्स के अपने कर्नेल ट्री में noref-filemap-read-with-llm नाम की एक ब्रांच दिखाई दी। इसमें आठ पैच हैं, सभी 9 और 10 अक्टूबर को टोरवाल्ड्स द्वारा लिखे और कमिट किए गए, 7.3-rc6 के ऊपर। इनमें आखिरी एक खाली कमिट है जिसमें व्याख्या के सिवा कुछ नहीं, और उस पाठ के अंत के पास “Tools” शीर्षक के नीचे एक अनुच्छेद है जो कर्नेल के बहुत कम कमिटों में मिलता है:
“कोड, परीक्षण कार्यक्रम, ऊपर दी गई सूची के पीछे की समीक्षा और इस पाठ का पहला मसौदा — ये सब मेरे निर्देशन में एक एलएलएम कोडिंग सहायक (Claude Code) के साथ किए गए। मापें मेरी अपनी मशीन पर चलाई गईं।”
Phoronix ने, जो 7.3-rc7 की प्रतीक्षा करते हुए इस ब्रांच पर पहुँचा, लिखा कि टोरवाल्ड्स अपने मुख्य रिपॉज़िटरी में शायद ही कभी काम की ब्रांचें रखते हैं। ये आठों कमिट master में नहीं हैं, और उन्होंने यह नहीं कहा कि ये 7.4 की मर्ज विंडो में जाएँगे या नहीं।
समस्या एक कैश लाइन की है
यह शृंखला उस प्रतिस्पर्धा-समस्या पर वार करती है जिसे मैथ्यू विलकॉक्स ने 2024 में एक ग्राहक के कार्यभार से उठाया था। जब कई थ्रेड एक ही फ़ाइल से छोटी-छोटी मात्राएँ पढ़ते हैं, तो हर पठन उस folio पर एक संदर्भ लेता और छोड़ता है जो पृष्ठ को थामे है, इसलिए हर पठन struct page की वही कैश लाइन दो बार लिखता है। टोरवाल्ड्स के लैपटॉप पर — चार कोर और आठ थ्रेड वाला i7-8565U — एक ही पृष्ठ पर 16 बाइट के pread() कॉल करते आठ थ्रेड सारे load HITMs का 99.92% उसी एक लाइन पर डाल देते हैं।
उनका समाधान यह है कि संदर्भ लिया ही न जाए। पृष्ठ कैश से हटाया गया folio अब पृष्ठ आवंटक के पास केवल एक RCU ग्रेस पीरियड के बाद लौटता है, यानी rcu_read_lock() के तहत मिला कोई पृष्ठ तब तक उस फ़ाइल का डेटा थामे रहता है जब तक लॉक नहीं छूटता। फिर पठन सीधे उपयोगकर्ता बफ़र में नकल करता है, पेज फ़ॉल्ट बंद रखकर: न संदर्भ, न स्टैक पर बीच का बफ़र, न नकल के बाद जाँच, और न पठन के आकार की कोई सीमा।
टोरवाल्ड्स लिखते हैं कि पिछले प्रयास बिना संदर्भ के स्टैक बफ़र में नकल करते और बाद में सत्यापन करते थे, और “वहीं रुक गए जहाँ सत्यापन देख ही नहीं सकता”: मुक्ति, पुनः उपयोग और उसी इंडेक्स पर फिर से डालना, माइग्रेशन, और ऐसी स्मृति पढ़ना जो अब पृष्ठ कैश रही ही नहीं — जैसे secretmem, अस्वीकृत स्मृति और “या इससे भी बुरा, अवांछित पठन-प्रभावों वाला MMIO”। मुक्ति टालने से ये स्थितियाँ पकड़ी नहीं जातीं, हट जाती हैं।
तीन गुना पठन, और 30,538 HITM घटकर 101
कमिट संदेश की संख्याएँ एक ही मशीन से हैं, ext4 पर, सीपीयू शमन और CONFIG_HARDENED_USERCOPY बंद रखकर। एक पृष्ठ से 16 बाइट पढ़ते आठ थ्रेड के साथ, मूल कर्नेल प्रति सेकंड 99 से 104 लाख पठन करता है, प्रति पठन 2,937–2,975 कर्नेल चक्र पर। शृंखला के साथ वह 3 से 3.3 करोड़ करता है, 725–726 चक्र पर। चार थ्रेड, प्रति कोर एक, 89–116 लाख से बढ़कर 2.5–2.6 करोड़ हो जाते हैं। perf c2c से मापे गए load HITMs 30,538 से गिरकर 101 रह जाते हैं।
इसकी कीमत वह स्मृति है जो ग्रेस पीरियड की प्रतीक्षा में कतार में पड़ी रहती है, और टोरवाल्ड्स इसी हिस्से को सबसे कम सुलझा हुआ कहते हैं। संदेश में उद्धृत विलकॉक्स की आपत्ति यह थी कि “इतनी सारी स्मृति को पुनः उपयोग की प्रतीक्षा में रखना बस बहुत जोखिम भरा लगता है”। पैच 7 और 8 इसी को थामने के लिए हैं: किसी सीपीयू पर 1,024 से अधिक पृष्ठ लंबित होने पर एक दूसरा कार्य-तत्व synchronize_rcu_expedited() बुलाकर सूची मुक्त करता है, जो छेद करते चार प्रोसेसों के साथ प्रति सेकंड 4,600 बार होता है — जबकि उसी फ़ंक्शन के दस्तावेज़ कहते हैं कि इसे लूप में न बुलाया जाए। टोरवाल्ड्स खुद यह चिह्नित करते हैं: “क्या इनके बिना छोटा ग्रेस पीरियड पाने का कोई तरीका है?”
जो उन्होंने नहीं परखा
संदेश उस सूची के साथ खत्म होता है जिसके विरुद्ध शृंखला नहीं चलाई गई: एक वर्चुअल मशीन के एक पुनरुत्पादक से आगे की स्मृति-दबाव स्थितियाँ, lockdep, KASAN, clang से बना कर्नेल, 32-बिट, CONFIG_HARDENED_USERCOPY, और “इस एक के सिवा कोई भी मशीन”। पैच 8 के शेड्यूलर बदलाव पर वे लिखते हैं: “मुझे यकीन नहीं कि दिशा यही है; मैं चाहूँगा कि मुक्त करने वाला कार्य कुछ समकालिक करे जो शेड्यूलर को अकेला छोड़ दे।”
औज़ार से ज़्यादा यही हिस्सा देखने लायक है। टोरवाल्ड्स ने प्रदर्शन के लिहाज़ से नाज़ुक स्मृति-प्रबंधन शृंखला प्रकाशित की है, कोड का श्रेय एक सहायक को दिया है, मापें अपने पास रखी हैं, और उपतंत्र के अनुरक्षकों के सामने दो खुले सवाल छोड़े हैं। मेलिंग सूची की समीक्षा में यह टिकती है या नहीं, यह उनके लैपटॉप पर तेज़ चलने से अलग परीक्षा है।
