קיבולת היא הכמות הכוללת של משאב כלשהו (מעבד, GPU וכו') שיש למכשיר בפרק זמן מסוים. בדף הזה נסביר איך לזהות בעיות שקשורות לקיבולת ולטפל בהן.
תגובה איטית של הרגולטור
כדי למנוע תנודות חדות, מנהל תדר המעבד צריך להגיב במהירות לעומסי עבודה תנודתיים. רוב האפליקציות לממשק משתמש פועלות לפי אותו דפוס בסיסי:
- המשתמש קורא את המסך.
- המשתמש נוגע במסך: מקשיק על לחצן, גולל וכו'.
- המסך גולל, משתנה או מופיעה בו אנימציה כלשהי בתגובה להזנת קלט.
- המערכת נכנסת למצב רגיעה בזמן הצגת תוכן חדש.
- המשתמש חוזר לקריאת המסך.
במכשירי Pixel ו-Nexus מופעלת שיפורי המגע כדי לשנות את התנהגות ה-governor (ומנהל התזמון) של המעבד במגע. כדי למנוע עלייה איטית לתדירות שעון גבוהה (שעלולה לגרום לכך שהמכשיר יפסיק להציג פריימים במגע), בדרך כלל ההגדרה 'שיפור המגע' מגדירה סף תדירות ב-CPU כדי להבטיח שיהיו מספיק משאבי CPU לשימוש במגע. הרצפה תישאר במצב הזה למשך זמן מה אחרי המגע (בדרך כלל כ-2 שניות).
ב-Pixel נעשה שימוש גם ב-cgroup של schedtune שסופק על ידי תזמון אנרגטי (EAS) כאות נוסף לשיפור הביצועים במגע: האפליקציות המובילות מקבלות משקל נוסף דרך schedtune כדי להבטיח שהן מקבלות מספיק קיבולת מעבד כדי לפעול במהירות. במכשירי Nexus 5X ו-6P יש פער ביצועים גדול בהרבה בין אשכולות המעבדים הקטנים והגדולים (A53 ו-A57, בהתאמה) בהשוואה ל-Pixel עם מעבד Kryo. גילינו שהאשכול הקטן של מעבדי ה-CPU לא תמיד מתאים לעיבוד חלק של ממשק המשתמש, במיוחד בהתחשב במקורות אחרים של רעידות במכשיר.
בהתאם, ב-Nexus 5X וב-6P, התכונה 'שיפור הביצועים במגע' משנה את התנהגות מתזמן המשימות כדי להגדיל את הסיכוי שאפליקציות בחזית יועברו ליבות הגדולות (הרעיון דומה לרצפה בתדירות המעבד). בלי השינוי בלוח הזמנים, שיגדיל את הסיכוי שהאפליקציות שבחזית יועברו לאשכולות המעבדים הגדולים, יכול להיות שלאפליקציות שבחזית לא תהיה מספיק קיבולת מעבד כדי לבצע רינדור עד שלוח הזמנים יחליט לאזן את העומס של השרשור לליבת מעבד גדולה. שינוי התנהגות מתזמן המשימות במהלך שיפור הביצועים במגע מגדיל את הסבירות ששרשור של ממשק המשתמש יפעל מיידית בליבה גדולה, וכך ימנע תנודות חדות בביצועים, בלי לאלץ אותו לפעול תמיד בליבה גדולה, דבר שעלול להשפיע באופן חמור על צריכת החשמל.
ויסות נתונים תרמי
צמצום תרמי מתרחש כאשר המכשיר צריך לצמצם את הפלט התרמי הכולל שלו, בדרך כלל על ידי צמצום השעונים של המעבד, של יחידת ה-GPU ושל זיכרון ה-DRAM. לא מפתיע שהתוצאה של כך היא לרוב תנודות בפריימים, כי יכול להיות שהמערכת לא תוכל לספק מספיק קיבולת לעיבוד בחלון זמן נתון. הדרך היחידה למנוע הגבלת הביצועים כתוצאה מהתחממות היא להשתמש בפחות חשמל. יש כמה דרכים לעשות זאת, אבל על סמך הניסיון שלנו עם SOCs קודמים, יש לנו כמה המלצות לספקי מערכות.
קודם כול, כשמפתחים SOC חדש עם ארכיטקטורות מעבדים הטרוגניות, חשוב לוודא שהקשתות של הביצועים/W של אשכולות המעבדים חופפות. עקומת הביצועים/הספק הכוללת של המעבד כולו צריכה להיות קו רציף. הפסקות בקשתה של עקומת הביצועים/הואט מאלצות את מתזמן המשימות ואת ה-frequency governor לנחש מה נחוץ לעומס העבודה. כדי למנוע תנודות חדות, מתזמן המשימות ואת ה-frequency governor נותנים לעומס העבודה יותר קיבולת ממה שהוא צריך. כתוצאה מכך, נוצר בזבוז של אנרגיה, שתורם לוויסות תרמי.
נניח שמדובר ב-SOC היפותטי עם שני אשכולות של מעבדים:
- באשכול 1, האשכול הקטן, צריכת האנרגיה יכולה לנוע בין 100 ל-300mW, והציון שלו במדד התפוקה הוא 100 עד 300, בהתאם לשעונים.
- באשכול 2, האשכול הגדול, אפשר להוציא בין 1,000 ל-1,600mW, והציון שלו באותו מדד של תפוקת נתונים הוא בין 800 ל-1,200, בהתאם לשעונים.
במסגרת מדד הביצועים הזה, ציון גבוה יותר מייצג מהירות גבוהה יותר. מהירות גבוהה יותר לא תמיד עדיף על מהירות נמוכה יותר, כי מהירות גבוהה יותר = צריכת חשמל גבוהה יותר.
אם מתזמן המשימות סבור שעומס העבודה של ממשק המשתמש ידרוש ציון שווה ערך ל-310 במדד העברת הנתונים הזה, האפשרות הטובה ביותר כדי למנוע תנודות חדות בביצועים היא להריץ את האשכולות הגדולים בתדירות הנמוכה ביותר, וכך לבזבז כמות משמעותית של חשמל. (הדבר תלוי בהתנהגות של cpuidle ובמרוץ ל-idle. קל יותר לבצע אופטימיזציה ל-SOC עם עקומות רציפות של ביצועים/W).
שנית, להשתמש ב-cpusets. חשוב לוודא שהפעלתם את cpusets בליבה וב-BoardConfig.mk. צריך גם להגדיר את ההקצאות בפועל של cpuset בקובץ init.rc שספציפי למכשיר. ספקים מסוימים משאירים את התכונה הזו מושבתת ב-BSP שלהם, בתקווה שיוכלו להשתמש בטיפים אחרים כדי להשפיע על התנהגות מתזמן המשימות. לדעתנו, זה לא הגיוני. קבוצות מעבדים (cpusets) מועילות כדי לוודא שאיזון העומסים בין מעבדים מתבצע באופן שמשקף את מה שהמשתמש עושה בפועל במכשיר.
המערכת ActivityManager מקצה אפליקציות לקבוצות שונות של מעבדים על סמך החשיבות היחסית שלהן (ראשיות, בחזית, ברקע), כאשר לאפליקציות חשובות יותר יש גישה רחבה יותר ליבות המעבד. כך אפשר להבטיח את איכות השירות באפליקציות שבחזית ובאפליקציות המובילות.
אפשר להשתמש ב-cpusets בהגדרות של מעבדים הומוגניים, אבל לא מומלץ לשלוח מכשיר עם הגדרות של מעבדים הטרוגניים בלי להפעיל את cpusets. Nexus 6P הוא מודל טוב לשימוש ב-cpusets בהגדרות של מעבדים הטרוגניים. תוכלו להשתמש בו כבסיס להגדרה של המכשיר שלכם.
בנוסף, cpusets מציע יתרונות בצריכת האנרגיה על ידי הבטחת ששלבים ברקע שלא חיוניים לביצועים לעולם לא יתאזנו בעומס לליבות מעבד גדולים, שבהם הם עלולים לצרוך הרבה יותר אנרגיה בלי להניב תועלת למשתמשים. כך אפשר גם למנוע הגבלת הספק תרמית. אמנם צמצום הביצועים כתוצאה מהתחממות היא בעיית קיבולת, אבל לשיפורים בתנודות יש השפעה משמעותית על ביצועי ממשק המשתמש במצב של צמצום הביצועים כתוצאה מהתחממות. מכיוון שהמערכת תפעל קרוב יותר ליכולת שלה ליצור 60FPS, נדרש פחות רעידות כדי לגרום לירידה בפריים.