استخدم لينوس تورفالدس، مبتكر Linux والمشرف الرئيسي على تطوير النواة، أداة Claude Code من Anthropic للمساعدة في معالجة اختناق عمره أكثر من عامين في مسار قراءة الملفات. وقدمت سلسلة من 10 رقع تحسناً بلغ 23 ضعفاً في معدل القراءة ضمن اختبار اصطناعي على جهاز Threadripper ذي 64 نواة، لكن مراجعي نواة Linux اكتشفوا لاحقاً حالة سباق وأثاروا أسئلة حول سلامة تصميم استعادة الذاكرة، ما يعني أن الرقع لم تُدمج بعد.
مشكلة في عدادات مراجع ذاكرة الصفحات
يرتبط العمل بتنافس على عدادات مراجع الكائنات المعروفة باسم folios داخل page cache، وهي طبقة تحتفظ بالبيانات المقروءة من الملفات لتسريع الوصول إليها. أُبلغ عن الاختناق في عام 2024 بعدما ظهر في حمل عمل لدى أحد العملاء، وأظهرت اختبارات على حاسوب تورفالدس المحمول أن هذا التنافس مثل 99.92% من عمليات HITM عبر الأنوية في اختبار يستخدم ثمانية خيوط.
قال تورفالدس إنه أمضى 18 شهراً يشغّل نسخة معيبة من إصلاحه السابق للمشكلة، بينما واجه مطورون آخرون مشكلات في محاولاتهم. وتستهدف الرقع الجديدة إزالة عمليات زيادة وإنقاص مراجع folio من مسار القراءة المخزنة الأكثر استخداماً، مع تحذير تورفالدس من أن المكاسب ستكون أصغر بكثير في أحمال العمل الواقعية مقارنة بالاختبار الاصطناعي.
دور Claude Code وحدود النتيجة
ظهرت في شجرة تورفالدس فرع تجريبي باسم noref-filemap-read-with-llm، ثم تضمنت السلسلة شرحاً لدور Claude Code. ووفق ما أورده تورفالدس، كتبت الأداة التنفيذ والاختبارات والتوثيق الأولي، كما راجعت الشيفرة تحت توجيهه، بينما تولى هو تشغيل اختبارات الأداء بنفسه.
رفعت السلسلة الأولى معدل القراءة على حاسوبه المحمول من نحو 10 ملايين إلى 33 مليون قراءة في الثانية، وخفضت عدد دورات النواة لكل قراءة من حوالي 2,950 إلى 725. أما السلسلة المنقحة فرفعت الأداء على جهاز Threadripper من 13.3 مليون إلى 304 ملايين قراءة في الثانية تحت ضغط عالٍ، مع انخفاض الدورات لكل قراءة من قرابة 20,000 إلى 735.
لماذا لا تكفي أرقام الأداء؟
جاء التحسن مع تكاليف محتملة. فقد كان التنفيذ الأول يفرض فترة انتظار مستعجلة عند تجاوز وحدة المعالجة المركزية 1,024 صفحة مؤجلة الاستعادة. كما أدت القراءات إلى صفحات مستخدم غير مرتبطة إلى خطأ إضافي قبل العودة إلى المسار القائم، فارتفعت كلفة قراءة أحادية الخيط بحجم 16 بايتاً من نحو 4,150 إلى 6,550 دورة. ولم يتضح بعد ما إذا كانت هذه النكسة ستبقى في إصدار rcu-free-v3.
المراجعة كشفت الخطر الأهم
اعترض Matthew Wilcox على استخدام العلم الجديد PG_rcu_free واقترح بديلاً يعتمد على نوع الصفحة وآلية مختلفة لاستعادة folios غير النشطة. كما اقترح Kiryl Shutsemau قصر العلم على الأنظمة ذات 64 بت، وهو اتجاه أيده David Hildenbrand.
واكتشف Shutsemau أيضاً حالة سباق في الدالة filemap_read_rcu_batch(): فقد يؤدي استبدال folio ثم توسيع حجم الملف إلى كشف بيانات لم تُكتب فعلياً. واقترح تورفالدس قراءة حجم الملف في وقت أبكر وتجميع عمليات التحقق، وهو ما أُدرج في رقعة منقحة.
القراءة التحريرية من certi.news: تُظهر الحالة أن أدوات البرمجة بالذكاء الاصطناعي تستطيع الوصول سريعاً إلى تحسينات كبيرة في اختبارات النواة، لكنها لا تلغي الحاجة إلى مراجعة متخصصة تفهم التزامن ودورة حياة الذاكرة. الأرقام القياسية هنا تثبت مكسباً في بيئة محددة، لا جاهزية تلقائية للدمج أو ضماناً لسلامة التنفيذ.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.