ظرفیت کل مقداری از منابع (CPU، GPU و غیره) است که یک دستگاه در مدت زمان مشخصی در اختیار دارد. این صفحه نحوه شناسایی و رسیدگی به مسائل مربوط به jank ظرفیت را شرح می دهد.
فرماندار دیر واکنش نشان می دهد
برای جلوگیری از jank، تنظیم کننده فرکانس CPU باید بتواند به سرعت به بارهای کاری انفجاری پاسخ دهد. اکثر برنامه های UI از الگوی اصلی یکسانی پیروی می کنند:
- کاربر در حال خواندن صفحه نمایش است.
- کاربر صفحه را لمس می کند: روی یک دکمه ضربه می زند، اسکرول می کند و غیره.
- صفحه نمایش اسکرول می‌کند، فعالیت‌ها را تغییر می‌دهد، یا به نوعی در پاسخ به ورودی متحرک می‌شود.
- با نمایش محتوای جدید، سیستم خاموش می شود.
- کاربر به خواندن صفحه باز می گردد.
دستگاه‌های Pixel و Nexus برای تغییر رفتار تنظیم‌کننده فرکانس (و زمانبندی) CPU در لمس، تقویت لمسی را اجرا می‌کنند. برای جلوگیری از رمپ آهسته به فرکانس ساعت بالا (که می‌تواند باعث افت فریم در هنگام لمس دستگاه شود)، بوست لمسی معمولاً یک طبقه فرکانس را روی CPU تنظیم می‌کند تا اطمینان حاصل شود که ظرفیت CPU زیادی در لمس در دسترس است. یک طبقه پس از لمس مدتی طول می کشد (معمولاً حدود دو ثانیه).
Pixel همچنین از schedtune cgroup ارائه شده توسط Energy Aware Scheduling (EAS) به عنوان سیگنال تقویت لمسی اضافی استفاده می‌کند: برنامه‌های کاربردی برتر از طریق Schedtune وزن بیشتری دریافت می‌کنند تا مطمئن شوند ظرفیت CPU کافی برای اجرای سریع دارند. Nexus 5X و 6P نسبت به Pixel با CPU Kryo، شکاف عملکردی بسیار بیشتری بین کلاسترهای کوچک و بزرگ CPU (به ترتیب A53 و A57) دارند. ما متوجه شدیم که خوشه کوچک CPU همیشه برای رندر صاف رابط کاربری مناسب نیست، به خصوص با توجه به منابع دیگر از لرزش در دستگاه.
بر این اساس، در Nexus 5X و 6P، تقویت لمسی رفتار زمانبندی را تغییر می‌دهد تا احتمال انتقال برنامه‌های پیش‌زمینه به هسته‌های بزرگ را افزایش دهد (این از نظر مفهومی مشابه فرکانس طبقه‌بندی CPU است). بدون تغییر زمانبندی برای افزایش احتمال انتقال برنامه‌های پیش‌زمینه به خوشه بزرگ CPU، برنامه‌های پیش‌زمینه ممکن است ظرفیت CPU کافی برای رندر کردن نداشته باشند تا زمانی که زمان‌بند تصمیم به بارگذاری تعادل رشته به یک هسته بزرگ CPU بگیرد. با تغییر رفتار زمانبندی در طول تقویت لمس، احتمال بیشتری وجود دارد که یک رشته رابط کاربری فوراً روی یک هسته بزرگ اجرا شود و از jank اجتناب کند در حالی که مجبور نیست همیشه روی یک هسته بزرگ اجرا شود، که می‌تواند تأثیرات شدیدی بر مصرف انرژی داشته باشد.
دریچه گاز حرارتی
شتاب حرارتی زمانی اتفاق می‌افتد که دستگاه باید خروجی حرارتی کلی خود را کاهش دهد، که معمولاً با کاهش ساعت‌های CPU، GPU و DRAM انجام می‌شود. جای تعجب نیست که این اغلب منجر به jank می شود زیرا ممکن است سیستم دیگر قادر به ارائه ظرفیت کافی برای رندر در یک زمان مشخص نباشد. تنها راه برای جلوگیری از انقباض حرارتی استفاده از توان کمتر است. راه‌های زیادی برای انجام این کار وجود ندارد، اما بر اساس تجربیات ما در SOCهای گذشته، توصیه‌هایی برای فروشندگان سیستم داریم.
ابتدا، هنگام ساخت یک SOC جدید با معماری‌های CPU ناهمگن، اطمینان حاصل کنید که منحنی‌های عملکرد/W خوشه‌های CPU همپوشانی دارند. منحنی عملکرد کلی/W برای کل پردازنده باید یک خط پیوسته باشد. ناپیوستگی در منحنی perf/W، زمان‌بندی‌کننده و تنظیم‌کننده فرکانس را مجبور می‌کند حدس بزند که یک حجم کاری به چه چیزی نیاز دارد. برای جلوگیری از jank، زمانبندی و تنظیم‌کننده فرکانس اشتباه می‌کنند که به حجم کاری بیش از حد نیاز ظرفیت می‌دهد. این منجر به صرف انرژی بیش از حد می شود که به دریچه گاز حرارتی کمک می کند.
یک SOC فرضی با دو کلاستر CPU را تصور کنید:
- خوشه 1، خوشه کوچک، می تواند بین 100 تا 300 میلی وات مصرف کند و بسته به ساعت، در یک معیار توان عملیاتی بین 100 تا 300 امتیاز دارد.
- خوشه 2، خوشه بزرگ، می تواند بین 1000 تا 1600 مگاوات مصرف کند و بسته به ساعت، بین 800 تا 1200 در همان معیار توان عملیاتی امتیاز می گیرد.
در این معیار، امتیاز بالاتر سریعتر است. در حالی که مطلوبتر از کندتر نیست، سریعتر == مصرف انرژی بیشتر.
اگر زمانبندی فکر می‌کند که حجم کاری UI به امتیازی معادل 310 در آن معیار توان نیاز دارد، بهترین گزینه برای جلوگیری از jank اجرای خوشه بزرگ در پایین‌ترین فرکانس است که انرژی قابل توجهی را هدر می‌دهد. (این به رفتار cpuidle و مسابقه تا بیکار بستگی دارد؛ SOCهایی با منحنی perf/W پیوسته برای بهینه سازی آسان تر هستند.)
دوم، از cpusets استفاده کنید. اطمینان حاصل کنید که cpusets را در هسته خود و در BoardConfig.mk خود فعال کرده اید. همچنین باید تخصیص cpuset واقعی را در init.rc مخصوص دستگاه خود تنظیم کنید. برخی از فروشندگان این ویژگی را در BSP های خود غیرفعال می کنند به این امید که بتوانند از نکات دیگری برای تأثیرگذاری بر رفتار زمانبندی استفاده کنند. ما احساس می کنیم این معنی ندارد. cpusets برای حصول اطمینان از اینکه تعادل بار بین CPU ها به گونه ای انجام می شود که نشان دهنده آنچه کاربر واقعاً روی دستگاه انجام می دهد، مفید است.
ActivityManager برنامه‌ها را بر اساس اهمیت نسبی آن برنامه‌ها (بالا، پیش‌زمینه، پس‌زمینه) به cpusets مختلف اختصاص می‌دهد و برنامه‌های مهم‌تر دسترسی بیشتری به هسته‌های CPU دارند. این به تضمین کیفیت خدمات برای پیش زمینه و برنامه های برتر کمک می کند.
cpusets در پیکربندی‌های CPU همگن مفید هستند، اما نباید دستگاهی با پیکربندی CPU ناهمگن بدون فعال بودن cpusets ارسال کنید. Nexus 6P مدل خوبی برای نحوه استفاده از cpusets در پیکربندی‌های CPU ناهمگن است. از آن به عنوان مبنایی برای پیکربندی دستگاه خود استفاده کنید.
پردازنده‌های مرکزی همچنین با اطمینان از اینکه رشته‌های پس‌زمینه‌ای که از نظر عملکرد حیاتی نیستند، هرگز به هسته‌های بزرگ CPU متعادل نمی‌شوند، مزایای قدرت را ارائه می‌کنند، جایی که می‌توانند به میزان قابل‌توجهی انرژی بیشتری را بدون هیچ مزیتی برای کاربر مصرف کنند. این می تواند به جلوگیری از درگیری حرارتی نیز کمک کند. در حالی که گلوگاه حرارتی یک مشکل ظرفیت است، بهبودهای جیتر تأثیر بزرگی بر عملکرد رابط کاربری در هنگام دریچه گاز حرارتی دارند. از آنجایی که سیستم به توانایی خود برای رندر 60 فریم در ثانیه نزدیک‌تر خواهد بود، برای ایجاد یک فریم افت، لرزش کمتری لازم است.