السعة هي المبلغ الإجمالي لبعض الموارد (وحدة المعالجة المركزية، وحدة معالجة الرسومات، وما إلى ذلك) التي يمتلكها الجهاز خلال فترة زمنية معينة. توضح هذه الصفحة كيفية تحديد المشكلات غير المرغوب فيها المتعلقة بالسعة ومعالجتها.
الحاكم بطيء في الرد
لتجنب الأخطاء غير المرغوب فيها، يجب أن يكون منظم تردد وحدة المعالجة المركزية قادرًا على الاستجابة بسرعة لأحمال العمل المتقطعة. تتبع معظم تطبيقات واجهة المستخدم نفس النمط الأساسي:
- المستخدم يقرأ الشاشة.
- يلمس المستخدم الشاشة: ينقر على الزر، ويمرر، وما إلى ذلك.
- يتم تمرير الشاشة أو تغيير النشاط أو تحريكها بطريقة ما استجابةً للإدخال.
- يهدأ النظام عند عرض محتوى جديد.
- يعود المستخدم إلى قراءة الشاشة.
تقوم أجهزة Pixel وNexus بتنفيذ تعزيز اللمس لتعديل سلوك منظم تردد وحدة المعالجة المركزية (والمجدول) عند اللمس. لتجنب الانحدار البطيء إلى تردد الساعة العالي (مما قد يتسبب في إسقاط الجهاز للإطارات عند اللمس)، عادةً ما يقوم تعزيز اللمس بتعيين أرضية تردد على وحدة المعالجة المركزية لضمان توفر الكثير من سعة وحدة المعالجة المركزية عند اللمس. تستمر الأرضية لبعض الوقت بعد اللمس (عادةً حوالي ثانيتين).
يستخدم Pixel أيضًا مجموعة schedtune cgroup التي توفرها Energy Aware Scheduling (EAS) كإشارة إضافية لتعزيز اللمس: تحصل أفضل التطبيقات على وزن إضافي عبر schedtune لضمان حصولها على سعة كافية لوحدة المعالجة المركزية للتشغيل بسرعة. يتمتع جهازا Nexus 5X و6P بفجوة أداء أكبر بكثير بين مجموعات وحدة المعالجة المركزية الصغيرة والكبيرة (A53 وA57، على التوالي) مقارنة بجهاز Pixel المزود بوحدة المعالجة المركزية Kryo. لقد وجدنا أن مجموعة وحدة المعالجة المركزية الصغيرة لم تكن دائمًا كافية لعرض واجهة المستخدم بسلاسة، خاصة في ضوء مصادر عدم الاستقرار الأخرى على الجهاز.
وفقًا لذلك، في Nexus 5X و6P، يعمل تعزيز اللمس على تعديل سلوك المجدول لزيادة احتمالية انتقال التطبيقات الأمامية إلى النوى الكبيرة (وهذا مشابه من الناحية المفاهيمية للأرضية على تردد وحدة المعالجة المركزية). بدون تغيير المجدول لزيادة احتمالية انتقال التطبيقات الأمامية إلى مجموعة وحدة المعالجة المركزية الكبيرة، قد لا تحتوي التطبيقات الأمامية على سعة كافية لوحدة المعالجة المركزية للعرض حتى يقرر المجدول تحميل موازنة الخيط إلى نواة وحدة المعالجة المركزية الكبيرة. من خلال تغيير سلوك المجدول أثناء تعزيز اللمس، من المرجح أن يتم تشغيل سلسلة واجهة المستخدم فورًا على نواة كبيرة وتجنب الأخطاء غير المرغوب فيها مع عدم إجبارها على التشغيل دائمًا على نواة كبيرة، مما قد يكون له تأثيرات شديدة على استهلاك الطاقة.
الاختناق الحراري
يحدث الاختناق الحراري عندما يتعين على الجهاز تقليل إنتاجه الحراري الإجمالي، ويتم ذلك عادةً عن طريق تقليل ساعات وحدة المعالجة المركزية (CPU) ووحدة معالجة الرسومات (GPU) وDRAM. ومن غير المستغرب أن يؤدي هذا غالبًا إلى حدوث خلل لأن النظام قد لا يكون قادرًا على توفير سعة كافية للعرض خلال فترة زمنية معينة. الطريقة الوحيدة لتجنب الاختناق الحراري هي استخدام طاقة أقل. لا توجد طرق كثيرة للقيام بذلك، ولكن استنادًا إلى تجاربنا مع مراكز عمليات الأمان السابقة، لدينا بعض التوصيات لموردي الأنظمة.
أولاً، عند إنشاء SOC جديد ببنيات وحدة المعالجة المركزية غير المتجانسة، تأكد من تداخل منحنيات الأداء/W لمجموعات وحدة المعالجة المركزية. يجب أن يكون منحنى الأداء العام/W للمعالج بأكمله خطًا مستمرًا. إن الانقطاعات في منحنى الأداء/W تجبر المجدول وحاكم التردد على تخمين ما يحتاجه عبء العمل؛ لمنع حدوث خلل، يخطئ المجدول وحاكم التردد من ناحية إعطاء عبء العمل سعة أكبر مما يتطلبه. وينتج عن ذلك استهلاك الكثير من الطاقة، مما يساهم في الاختناق الحراري.
تخيل شركة نفط الجنوب (SOC) افتراضية مع مجموعتين من وحدات المعالجة المركزية:
- يمكن للمجموعة 1، المجموعة الصغيرة، أن تنفق ما بين 100-300 ميجاوات وتسجل 100-300 في معيار الإنتاجية اعتمادًا على الساعات.
- يمكن للمجموعة 2، المجموعة الكبيرة، أن تنفق ما بين 1000 و1600 ميجاوات وتسجل ما بين 800 و1200 في نفس معيار الإنتاجية اعتمادًا على الساعات.
في هذا المعيار، تكون النتيجة الأعلى أسرع. في حين أن ليس أكثر من المرغوب فيه أبطأ وأسرع == استهلاك أكبر للطاقة.
إذا كان المجدول يعتقد أن عبء عمل واجهة المستخدم سيتطلب ما يعادل درجة 310 في معيار الإنتاجية هذا، فإن أفضل خيار لتجنب الأخطاء هو تشغيل المجموعة الكبيرة بأقل تردد، مما يؤدي إلى إهدار قدر كبير من الطاقة. (يعتمد هذا على سلوك cpuidle والسباق إلى الخمول؛ ومن الأسهل تحسين SOCs ذات منحنيات الأداء/W المستمرة.)
ثانيا، استخدم وحدات المعالجة المركزية. تأكد من تمكين وحدات المعالجة المركزية (cpusets) في النواة لديك وفي BoardConfig.mk الخاص بك. يجب عليك أيضًا إعداد تعيينات وحدة المعالجة المركزية الفعلية في init.rc الخاص بجهازك. يترك بعض البائعين هذا معطلاً في BSPs الخاصة بهم على أمل أن يتمكنوا من استخدام تلميحات أخرى للتأثير على سلوك المجدول؛ نشعر أن هذا غير منطقي. تعد مجموعات cpusets مفيدة لضمان إجراء موازنة التحميل بين وحدات المعالجة المركزية بطريقة تعكس ما يفعله المستخدم فعليًا على الجهاز.
يقوم ActivityManager بتعيين التطبيقات لوحدات المعالجة المركزية (CPUsets) المختلفة بناءً على الأهمية النسبية لتلك التطبيقات (الأعلى، المقدمة، الخلفية)، مع حصول التطبيقات الأكثر أهمية على وصول أكبر إلى مراكز وحدة المعالجة المركزية (CPU). يساعد هذا على ضمان جودة الخدمة للتطبيقات الأمامية والأعلى.
تعد مجموعات وحدات المعالجة المركزية مفيدة في تكوينات وحدة المعالجة المركزية المتجانسة، ولكن لا ينبغي عليك شحن جهاز بتكوين وحدة معالجة مركزية غير متجانسة دون تمكين مجموعات وحدات المعالجة المركزية. يعد Nexus 6P نموذجًا جيدًا لكيفية استخدام وحدات المعالجة المركزية (CPUsets) على تكوينات وحدة المعالجة المركزية غير المتجانسة؛ استخدم ذلك كأساس لتكوين جهازك الخاص.
توفر مجموعات cpusets أيضًا مزايا الطاقة من خلال ضمان أن سلاسل العمليات الخلفية التي ليست ذات أهمية كبيرة للأداء لا تحصل أبدًا على موازنة التحميل مع مراكز وحدة المعالجة المركزية الكبيرة، حيث يمكن أن تنفق قدرًا أكبر بكثير من الطاقة دون أي فائدة يدركها المستخدم. يمكن أن يساعد هذا في تجنب الاختناق الحراري أيضًا. في حين أن الاختناق الحراري يمثل مشكلة تتعلق بالسعة، فإن تحسينات عدم الاستقرار لها تأثير كبير على أداء واجهة المستخدم عند الاختناق الحراري. نظرًا لأن النظام سيعمل بشكل أقرب إلى قدرته على عرض 60 إطارًا في الثانية، فإنه يتطلب اهتزازًا أقل للتسبب في إسقاط الإطار.