إصلاح الانحدار الشديد في أداء Linux الذي رصده Torvalds

قبل انقطاع الإنترنت والكهرباء عن Linus Torvalds بسبب عاصفة ثلجية وبالتالي التأثير على نافذة دمج Linux 6.8، كانت عطلة نهاية الأسبوع الخاصة به في حالة صعبة بالفعل بسبب مواجهة تراجع في الأداء مع كود Linux 6.8 الجديد الذي كان يتسبب في إنشاء نواة Linux الخاصة به. يكون ضعف ما كان عليه مع النوى السابقة. تمكن أحد مهندسي AMD Linux من إعادة إنتاج الانحدار ومع المطورين الرئيسيين، يوجد الآن حل مؤكد لهذه المشكلة في أحدث تعليمات برمجية للجدولة.

في المناقشة حول تراجع الأداء الكبير الذي أبلغ عنه لينوس تورفالدس والذي نشأ عن تغييرات المجدول في Linux 6.8، بالنسبة للالتزام المقسم، لم يكن واضحًا على الفور للمطور المعني بالسبب الذي تسبب في الانحدار. وفي المناقشة التي تلت ذلك، تحدث وايز كارني من AMD ذكرت أنه أيضًا يمكنه إعادة إنتاج الانحدار. بدلاً من AMD Ryzen Threadripper المتطور مثل الذي يستخدمه Torvalds، كان Wyes يستخدم سطح مكتب متواضع من AMD Ryzen 5600G. إحدى الملاحظات المهمة التي طرحها هي أن هذا يتم إعادة إنتاجه فقط في حالة تعطيل ACPI CPPC من BIOS واستخدام ACPI CPUFreq مع حاكم Schedutil.

تدعم معظم أنظمة AMD Zen 2 والأنظمة الأحدث ACPI CPPC، وبالتالي مع النوى الحديثة على جانب Ryzen تستخدم عادةً برنامج تشغيل AMD P-State الجديد. ولكن بالنسبة لأنظمة Zen 2 / Zen 3 والإصدارات الأقدم (أو تلك التي تقوم بتعطيل CPPC من BIOS)، لا يزال برنامج تشغيل CPUFreq مستخدمًا وعادة ما يكون حاكم تردد وحدة المعالجة المركزية الافتراضي هو “Schedutil” للاستفادة من بيانات استخدام المجدول.

ومن خلال سلسلة الرسائل هذه في القائمة البريدية، تم اقتراح تصحيح وتمت مناقشة المشكلات المحددة المتعلقة بهذا الانحدار. في النهاية، يعتقد فنسنت جيتو أن لديه حلًا للانحدار وتمكن وايز من اختبار التصحيح بنجاح.

لقد أرسل Guittot الآن مجدول/عادل: إصلاح اختيار التردد للحالة غير الثابتة كتصحيح لإصلاح هذا الانحدار السيئ على كود Linux 6.8 الجديد عند استخدام ACPI CPUFreq + Schedutil. يشرح مع التصحيح:

“عند عدم تمكين ثبات التردد، تقوم get_capacity_ref_freq(policy) بإرجاع التردد الحالي وهامش الأداء المطبق بواسطة Map_util_perf()، مما يمكّن الاستخدام من تجاوز الحد الأقصى لسعة الحوسبة وتحديد تردد أعلى من التردد الحالي.

يتم الآن تطبيق هامش الأداء في وقت مبكر من المسار لمراعاة بعض قيود الاستخدام ولا يمكننا الحصول على استخدام أعلى من الحد الأقصى لسعة الحوسبة.

يجب علينا استخدام تردد أعلى من التردد الحالي للحصول على فرصة لتحديد OPP أعلى عندما يتم استخدام التردد الحالي بالكامل. قم بتطبيق نفس الهامش وإرجاع تردد أعلى بنسبة 25% من التردد الحالي من أجل التبديل إلى OPP التالي قبل أن نستخدم وحدة المعالجة المركزية بالكامل في المعالج الحالي.”

في النهاية، كان إصلاح التعليمات البرمجية من سطر واحد لمعالجة تراجع الأداء هذا هو الذي تسبب في زيادة بنيات النواة الفارغة الخاصة بـ Linus Torvalds من 22 ثانية إلى 44 ثانية.

بافتراض أن كل شيء يستمر في الاختبار بشكل جيد مع التصحيح الجديد، فمن المفترض أن يشق الإصلاح طريقه إلى كود Linux 6.8 Git بمجرد استعادة الإنترنت والكهرباء لـ Linus Torvalds.