كيف تساعد EAS في جعل Google Pixel أسرع هاتف يعمل بنظام Android

في الماضي البعيد، عندما كان Linux مجرد فكرة في ذهن Linus Torvalds، كانت وحدات المعالجة المركزية عبارة عن كيانات أحادية النواة تتطلب قدرًا هائلاً من الطاقة مقابل القليل من الطاقة. أول معالج متاح تجاريًا على الإطلاق، Intel 4004، كان يعمل بمعدل ساعة يبلغ 740 كيلو هرتز على نواة واحدة. في ذلك الوقت، لم تكن هناك حاجة لجدولة التحميل. تم حجز جدولة التحميل لـ "الشركات العملاقة" ثنائية النواة مثل IBM Power 4 الذي صدر بعد بضعة عقود. تم تشغيلها بسرعة 1.1 جيجا هرتز إلى 1.9 جيجا هرتز وتطلبت برامج ونظامًا لاستخدام هذه النوى بشكل صحيح. كيف انتقلنا من هذه الآلات إلى خوارزميات برمجية تستخدم نوى متعددة؟ ربما تكون قد سمعت عن "الجدولة المدركة للطاقة" (EAS) في منتدياتنا من قبل. إنه جزء من السبب وراء الأداء الجيد للهواتف الذكية Google Pixel. ما هو الشيء الرائع في EAS وكيف وصلنا إلى هذه النقطة؟ قبل أن نتمكن من شرح ذلك، نحتاج إلى التحدث عن برامج جدولة التحميل لنظام التشغيل Linux.

---

تطور برامج جدولة تحميل Linux

جدولة جولة روبن

تعد المعالجة المستديرة مفهومًا بسيطًا للشرح والفهم، كما أنها أبسط لفهم عيوبه. يستخدم Round-Robin تقسيم الوقت لتخصيص الوقت لكل عملية. لنفترض أن لدينا أربع عمليات قيد التشغيل على جهاز الكمبيوتر الخاص بنا.

• العملية أ
• العملية ب
• العملية ج
• العملية د

الآن، دعونا نقوم بمهمة جدولة الجولة روبن. سنخصص 100 مللي ثانية (تقسيم الوقت) لكل عملية قبل الانتقال إلى العملية التالية. وهذا يعني أن العملية "أ" يمكن أن تستغرق 100 مللي ثانية للقيام بمعالجتها، ثم تنتقل إلى العملية "ب" وهكذا. إذا كانت مهمة التطبيق تستغرق 250 مللي ثانية لإنجازها، فسوف يحتاج إلى المرور بهذه العملية 3 مرات فقط لإنهاء عمله! الآن قم بتوسيع نطاق ذلك عبر مراكز مختلفة، بحيث يتم تخصيص العملية A والعملية B للنواة 1، ويتم تخصيص العملية C والعملية D للنواة 2. تم استبدال ذلك بجدولة O(n) (والتي كانت تشبه نظام round-robin، ولكن باستخدام العصور والسماح بالتخصيص الديناميكي لـ الوقت)، ثم جدولة O(1) (تقليل النفقات العامة، ودعم العمليات غير المحدود)، ثم أخيرًا المجدول العادل تمامًا (لجنة الأمن الغذائي العالمي). تم دمج CFS في إصدار Linux kernel 2.6.23 في أكتوبر 2007. لقد تم إصلاحه منذ ذلك الحين ولا يزال هو المجدول الافتراضي في أنظمة Linux.

جدولة عادلة تماما

إن برنامج Completely Fair Tabler موجود في Android منذ بدايته ويتم استخدامه على الأجهزة غير الكبيرة. أجهزة صغيرة. ويستخدم خوارزمية ذكية لتحديد ترتيب المعالجة والوقت المخصص وما إلى ذلك. إنه مثال على التنفيذ العملي لخوارزمية الجدولة المدروسة جيدًا والتي تسمى "قائمة الانتظار العادلة الموزونة". يركز هذا بشكل أساسي على توفير الأولوية لعمليات النظام والعمليات الأخرى ذات الأولوية العالية التي تعمل على آلة. لو كان لتشغيل كبير. جهاز LITTLE، سيتم اعتبار جميع النوى متساوية. وهذا أمر سيء، حيث قد تضطر النوى منخفضة الطاقة إلى تشغيل تطبيقات مكثفة، أو الأسوأ من ذلك، قد يحدث العكس. قد يتم فك التشفير للاستماع إلى الموسيقى على النواة الكبيرة، على سبيل المثال، زيادة استهلاك الطاقة دون داع. هذا هو السبب في أننا بحاجة إلى جدولة جديدة للكبيرة. LITTLE، جهاز يمكنه بالفعل التعرف على الاختلاف في النوى والاستفادة منه بطريقة فعالة في استهلاك الطاقة. وهنا يأتي دور المعالجة المتعددة غير المتجانسة (HMP)، وهي أداة جدولة التحميل القياسية التي تعمل بها معظم هواتف Android الآن.

معالجة متعددة غير متجانسة

هذا هو برنامج جدولة التحميل القياسي لأي شركة كبيرة. جهاز صغير تم طرحه في السنوات الأخيرة، بخلاف Google Pixel. يستفيد HMP من الحجم الكبير. بنية LITTLE، تفوض الأولوية المنخفضة والعمل الأقل كثافة إلى النوى الصغيرة التي تستهلك طاقة أقل. يعد HMP "آمنًا" حيث يعرف ما يجب أن يذهب إلى النوى الكبيرة وما يجب أن يذهب إلى النوى الصغيرة، دون ارتكاب أخطاء. إنه يعمل فقط ويتطلب إعداده على جانب التطوير جهدًا أقل بكثير من شيء مثل EAS، والذي سنتطرق إليه بعد قليل. HMP هو مجرد امتداد لـ CFS لجعله مدركًا للطاقة.

لا يأخذ HMP التخمينات، ولا يتنبأ بالعمليات المستقبلية. وهذا أمر جيد، ولكن هذا هو السبب في أن الجهاز لا يمكن أن يكون سلسًا مثل الأجهزة التي تعمل بنظام EAS، ولهذا السبب أيضًا يستهلك بطارية أكثر قليلاً. يقودنا هذا أخيرًا إلى الجدولة المدركة للطاقة (EAS)، والتي أعتقد اعتقادًا راسخًا أنها المستقبل في تطوير ROM والنواة مع اعتماد المزيد من مصنعي المعدات الأصلية لها.

جدولة الطاقة واعية

تعد الجدولة المدركة للطاقة (EAS) هي الشيء الكبير التالي الذي يتحدث عنه المستخدمون في منتدياتنا. إذا كنت تستخدم OnePlus 3 (أو Google Pixel بالطبع) فمن المؤكد أنك سمعت عنه في المنتديات. تم إطلاقه في الاتجاه السائد باستخدام Qualcomm Snapdragon 845، لذا إذا كان لديك أحد هذه الأجهزة، فلديك بالفعل هاتف ذكي يدعم تقنية EAS. EAS في شكل حبات مثل ريندرزينيث و ROM مثل VertexOS و بيورفيوجن كانوا يستحوذون على منتديات OnePlus 3 في بدايتها. وبطبيعة الحال، يأتي Google Pixel أيضًا مزودًا بـ EAS. مع الوعود بتحسين عمر البطارية والأداء الأفضل، ما الفائدة؟

إن جدولة الطاقة المدركة ليست بسيطة بقدر ما هي ليست عالمية لكل جهاز مثل CFS أو HMP. يتطلب EAS فهم المعالج الذي يعمل عليه، بناءً على نموذج الطاقة. يتم تصنيع نماذج الطاقة هذه بواسطة فرق من المهندسين الذين يقومون بالاختبار والعمل باستمرار لتوفير الأداء الأمثل. نظرًا لأن Snapdragon 820 و821 متماثلان بشكل أساسي، فإن النواة المخصصة في OnePlus 3 تستخدم نموذج الطاقة Google Pixel. يمكن للأجهزة المزودة بـ Snapdragon 845 الاستفادة من EAS، كما يفعل OnePlus 6 إلى حد ما. إنه ليس مضبوطًا مثل جهاز Google Pixel، ولكنه ينجز المهمة. فيما يلي مثال على أنه على الرغم من أن هاتف OnePlus 6 يحتوي على معالج أفضل مع EAS، إلا أن هاتف Pixel 2 XL لا يزال يتفوق عليه في السلاسة. تم التقاط كلتا الصورتين من موقعنا مراجعة موجهة نحو السرعة من ون بلس 6.

إذا كنت تواجه مشكلة في فهم الرسوم البيانية، يمكنك إلقاء نظرة على الصورة أدناه للحصول على إرشادات. يشير أي شيء يتجاوز الخط الأخضر إلى سقوط الإطارات، وفي أسوأ الحالات، إلى تأتأة ملحوظة.

يعد تطبيق OnePlus 6 لـ EAS مثيرًا للاهتمام، حيث لا يبدو أنه تطبيق كامل مثلما تجده في Google Pixel مع نفس SoC. إن عمليات ضبط الجدولة ليست منطقية أيضًا، لذلك ربما يفسر هذا سبب عدم كفاءة الأداء كما تتوقع. إنه محافظ للغاية في استهلاك الطاقة، حيث يعطي النظام الأولوية لنوى الطاقة المنخفضة لغالبية العمل.

Tunables هي ببساطة مجموعة من المعلمات التي يتم تمريرها إلى حاكم وحدة المعالجة المركزية، والتي تغير كيفية تفاعل الحاكم مع مواقف معينة من حيث التردد. ثم يقرر المجدول أين يضع المهام على معالجات مختلفة. تم ضبط الأجهزة القابلة للضبط في OnePlus 6 لإعطاء الأولوية للعمل على النوى منخفضة الطاقة. ومن غير المفيد أيضًا أن يتمتع Google Pixel 2 بقدر كبير من تعزيز المدخلات، مما يجعل جميع النوى الثمانية متصلة بالإنترنت طوال الوقت. تستخدم Google أيضًا ملف موازن المقاطعة مما يساعد على إزالة قطرات الإطار وتحسين الأداء.

إذن كيف تعمل EAS؟ لماذا هو فعال جدا فقط في ظروف معينة؟

تقدم الجدولة المدركة للطاقة الحاجة إلى استخدام نموذج الطاقة، وكما ذكر أعلاه يتطلب الكثير من الاختبارات والعمل لجعله مثاليًا. تحاول EAS توحيد ثلاثة أجزاء أساسية مختلفة من النواة والتي تعمل جميعها بشكل مستقل، ويساعد نموذج الطاقة على توحيدها.

• جدولة Linux (CFS، المذكورة أعلاه)
• لينكس cpuidle
• لينكس cpufreq

إن توحيد الأجزاء الثلاثة ضمن المجدول وحسابها معًا يعطي إمكانية توفير الطاقة، حيث أن حسابها معًا يتيح لها أن تكون فعالة قدر الإمكان. يحاول CPUIdle تحديد متى يجب أن تنتقل وحدة المعالجة المركزية إلى وضع الخمول، بينما يحاول CPUFreq تحديد متى يجب رفع مستوى وحدة المعالجة المركزية أو خفضها. كلتا الوحدتين لهما الهدف الأساسي وهو توفير الطاقة. ليس هذا فحسب، بل يقوم بعد ذلك بتصنيف العمليات إلى أربع مجموعات، وهي أعلى التطبيق، وخلفية النظام، والمقدمة، والخلفية. يتم وضع المهام المقرر معالجتها في إحدى هذه الفئات، ثم يتم منح الفئة طاقة وحدة المعالجة المركزية ويتم تفويض العمل عبر مراكز مختلفة لوحدة المعالجة المركزية. يعد التطبيق العلوي هو الأولوية القصوى للإكمال، تليها المقدمة والخلفية ثم خلفية النظام. تتمتع الخلفية من الناحية الفنية بنفس الأولوية التي تتمتع بها خلفية النظام، ولكن عادةً ما تتمتع خلفية النظام أيضًا بإمكانية الوصول إلى عدد أكبر من النوى الصغيرة. في الواقع، تأخذ تقنية Energy Aware Scheduling الأجزاء الأساسية من Linux kernel وتوحدها كلها في عملية واحدة.

عند تنشيط الجهاز، ستختار EAS المركز في أقل حالة خمول، مما يقلل من الطاقة اللازمة لتنشيط الجهاز. وهذا يساعد على تقليل الطاقة المطلوبة في استخدام الجهاز، حيث أنه لن يقوم بإيقاظ المجموعة الكبيرة إذا لم تكن هناك حاجة لذلك. يعد تتبع الحمل أيضًا جزءًا بالغ الأهمية من EAS، وهناك خياران. يتم عادةً استخدام "تتبع التحميل لكل كيان" (PELT) لتتبع التحميل، ثم يتم استخدام المعلومات لتحديد الترددات وكيفية تفويض المهام عبر وحدة المعالجة المركزية. يمكن أيضًا استخدام "تتبع التحميل بمساعدة النافذة" (WALT) وهو ما يتم استخدامه في Google Pixel. العديد من ROMs EAS في منتدياتنا، مثل VertexOS، تختار استخدام WALT. ستصدر العديد من ROM نسختين من النواة مع WALT أو PELT، لذا فإن القرار متروك للمستخدم. يعد WALT أكثر اندفاعًا، مع وجود قمم عالية في تردد وحدة المعالجة المركزية بينما يحاول PELT أن يظل أكثر اتساقًا. لا يؤثر متتبع التحميل فعليًا على تردد وحدة المعالجة المركزية، فهو يخبر النظام فقط عن مدى استخدام وحدة المعالجة المركزية. يتطلب الاستخدام الأعلى لوحدة المعالجة المركزية ترددًا أعلى، وبالتالي فإن السمة الثابتة لـ PELT هي أنه يتسبب في زيادة تردد وحدة المعالجة المركزية لأعلى أو لأسفل ببطء. يميل نظام PELT إلى الانحراف نحو إعداد تقارير أعلى عن حمل وحدة المعالجة المركزية، لذلك قد يوفر أداءً أعلى بتكلفة بطارية أعلى. لا يمكن لأحد أن يقول حقًا في هذا الوقت ما هو نظام تتبع الحمل الأفضل، ومع ذلك، حيث يتم تصحيح وتحسين كلتا طريقتي تتبع الحمل باستمرار.

وفي كلتا الحالتين، من الواضح أنه بغض النظر عن طريقة تتبع الحمل المستخدمة، هناك زيادة في الكفاءة. فبدلاً من مجرد معالجة المهام على أي معالج، يتم تحليل المهمة وتقدير كمية الطاقة اللازمة لتشغيلها. ويعني تحديد المهام الذكي هذا أن المهام يتم إكمالها بطريقة أكثر كفاءة مع جعل النظام أسرع ككل. تدور EAS حول الحصول على واجهة مستخدم أكثر سلاسة ممكنة مع الحد الأدنى من استخدام الطاقة. هذا هو المكان الذي تلعب فيه المكونات الخارجية الأخرى مثل schedtune.

يتم تعريف Schedtune في كل مجموعة cgroup من خلال اثنين من أدوات الضبط التي تضمن التحكم الدقيق في المهام التي سيتم إكمالها. فهو لا يتحكم فقط في توزيع المهام على وحدات معالجة مركزية متعددة، ولكن أيضًا إذا كان يجب تضخيم الحمل المتصور لضمان إكمال المهام الحساسة للوقت بشكل أسرع. بهذه الطريقة، لن تتباطأ التطبيقات والخدمات الأمامية التي يستفيد منها المستخدم وتتسبب في حدوث مشكلات غير ضرورية في الأداء.

على الرغم من أن الجدولة المدركة للطاقة هي الشيء الكبير التالي، إلا أنه يمكن القول أيضًا أنها موجودة بالفعل منذ فترة. مع وصول المزيد والمزيد من الأجهزة إلى الاتجاه السائد باستخدام تقنية Energy Aware Scheduling، فقد بدأ عصر جديد من كفاءة المعالجة عبر الأجهزة المحمولة.

إيجابيات وسلبيات Round-Robin، CFS، HMP وEAS

على الرغم من أن مهاراتي الرسومية دون المستوى، إلا أنني قمت بتجميع صورة تلخص إيجابيات وسلبيات كل من هذه المجدولات.

---

أود أن أتقدم بشكر خاص إلى المساهم المعترف به في XDA مصطفى وائل الذي ساعدت تفسيراته للجوانب المختلفة لـ EAS بشكل كبير في جعل هذا المقال ممكنًا. أود أيضًا أن أشكر مطور XDA المعترف به مرح، مطور XDA المعترف به RenderBroken و مصطفى وائل لكتابته عن EAS. بالنسبة لأولئك منكم الذين وجدوا اهتمامًا بالأجزاء المتعلقة بـ EAS، لدى Linaro الكثير من الوثائق حول EAS والتي يمكنك قراءتها.