הסמארטפונים של גוגל פיקסל הם בין מכשירי האנדרואיד המהירים ביותר בשוק. Energy Aware Scheduling (EAS) הוא חלק מהסיבה שהטלפון כל כך חלק.
הרבה בעבר, כאשר לינוקס הייתה רק רעיון במוחו של לינוס טורוואלדס, מעבדים היו ישויות ליבה בודדות שדרשו כמות עצומה של אנרגיה עבור מעט כוח. המעבד הראשון אי פעם הזמין מסחרית, אינטל 4004, פעל בקצב שעון של 740kHz על ליבה אחת. אז, לא היה צורך במתזמן עומסים. תזמון העומס היה שמור ל"המותות" הכפולות הליבה כגון IBM Power 4 שיצא כמה עשורים לאחר מכן. אלה רצו במהירות של 1.1GHz עד 1.9GHz ודרשו תוכניות והמערכת כדי לנצל את הליבות הללו בצורה נכונה. איך הגענו מהמכונות האלה לאלגוריתמי תוכנה שעושים שימוש במספר ליבות? אולי שמעתם על Energy Aware Scheduling (EAS) בפורומים שלנו בעבר. זה חלק מהסיבה לכך שהסמארטפונים של גוגל פיקסל מתפקדים כל כך טובים. מה כל כך נהדר ב-EAS ואיך בכלל הגענו לנקודה הזו? לפני שנוכל להסביר זאת, עלינו לדבר על מתזמני עומס של לינוקס.
האבולוציה של מתזמני העומס של לינוקס
תזמון עגול רובין
עיבוד Round robin הוא מושג פשוט להסבר והבנה, ופשוט אפילו יותר לתפוס את החסרונות שלו. Round-robin משתמש בחיתוך זמן כדי להקצות זמן לכל תהליך. נניח שיש לנו ארבעה תהליכים שרצים במחשב שלנו.
- תהליך א
- תהליך ב'
- תהליך ג'
- תהליך ד'
עכשיו, בואו נעשה את העבודה של מתזמן הסיבוב-רובין. נקצה 100 מילישניות (חיצוב זמן) לכל תהליך לפני שנמשיך לתהליך הבא. זה אומר שתהליך A יכול לקחת 100 אלפיות שניות לבצע את העיבוד שלו, ואז הוא עובר לתהליך B וכן הלאה. אם העבודה של אפליקציה אורכת 250 מילישניות, היא תצטרך לעבור את התהליך הזה 3 פעמים רק כדי לסיים את עבודתה! כעת קנה קנה מידה זה על פני ליבות שונות, כך שתהליך A ותהליך B מוקצים לליבה 1, ותהליך C ותהליך D מוקצים לליבה 2. זה הוחלף בתזמון O(n) (שהיה כמו סיבוב רובין, אך תוך שימוש בתקופות ומאפשר הקצאה דינמית של זמן), ואז O(1) תזמון (תקורה ממוזערת, תמיכת תהליכים בלתי מוגבלת), ואז לבסוף מתזמן הוגן לחלוטין (CFS). CFS מוזג לגרסת ליבת לינוקס 2.6.23 באוקטובר 2007. מאז הוא עבר שיפוץ והוא עדיין מתזמן ברירת המחדל במערכות לינוקס.
מתזמן הוגן לחלוטין
ה-Completely Fair Scheduler קיים באנדרואיד מאז הקמתו ומשמש ב-non-big. מכשירים קטנים. הוא משתמש באלגוריתם חכם כדי לקבוע סדר עיבוד, זמן שהוקצה וכו'. זוהי דוגמה ליישום עובד של אלגוריתם התזמון הנלמד היטב הנקרא "תור הוגן משוקלל". זה בעצם מתמקד במתן עדיפות לתהליכי מערכת ותהליכים אחרים בעלי עדיפות גבוהה הפועלים על מְכוֹנָה. אם זה היה פועל על גדול. מכשיר קטן, כל הליבות ייתפסו כשוות. זה רע, שכן ליבות צריכת חשמל נמוכות עשויות להיאלץ להפעיל יישומים אינטנסיביים, או אפילו גרוע מכך, ההפך עשוי להתרחש. הפענוח להאזנה למוזיקה עשוי להתבצע על הליבה הגדולה, למשל, הגדלת צריכת החשמל ללא צורך. זו הסיבה שאנחנו צריכים מתזמן חדש עבור גדול. LITTLE, כזה שבאמת יכול לזהות ולנצל את ההבדל בליבות בצורה חסכונית. כאן נכנס לתמונה עיבוד רב-הטרוגני (HMP), מתזמן העומס הסטנדרטי שרוב טלפונים אנדרואיד פועלים כעת.
ריבוי עיבודים הטרוגניים
זהו מתזמן העומס הסטנדרטי עבור כל גדול. מכשיר קטן ששוחרר בשנים האחרונות, מלבד ה-Google Pixel. HMP עושה שימוש בגדול. מעט ארכיטקטורה, האצלת עדיפות נמוכה, עבודה פחות אינטנסיבית לליבות הקטנות שצורכות פחות חשמל. HMP הוא "בטוח" שבו הוא יודע מה צריך ללכת לליבות הגדולות ומה צריך ללכת לליבות הקטנות, מבלי לעשות טעויות. זה פשוט עובד ודורש הרבה פחות מאמץ להגדיר בצד הפיתוח מאשר משהו כמו EAS, אליו ניכנס עוד רגע. HMP הוא רק הרחבה של CFS כדי להפוך אותו למודע כוח.
HMP אינו לוקח ניחושים, ואינו חוזה תהליכים עתידיים. זה טוב אבל זו הסיבה שהמכשיר לא יכול להיות נוזלי כמו אלה שמריצים EAS וזו גם הסיבה שהוא צורך מעט יותר סוללה. זה, לבסוף, מביא אותנו ל-Energy Aware Scheduling (EAS), שאני מאמין בתוקף שהוא העתיד בפיתוח ROM וקרנל ככל שיותר יצרני OEM מאמצים אותו.
תזמון מודע לאנרגיה
Energy Aware Scheduling (EAS) הוא הדבר הגדול הבא שמשתמשים בפורומים שלנו מדברים עליו. אם אתה משתמש ב-OnePlus 3 (או ב-Google Pixel, ברור) בהחלט שמעתם על זה בפורומים. הוא הושק למיינסטרים עם ה-Qualcomm Snapdragon 845, כך שאם יש לך אחד מהמכשירים האלה כבר יש לך סמארטפון התומך EAS. EAS בצורה של גרעינים כגון RenderZenith ו-ROMs כגון VertexOS ו PureFusion כבשו את הפורומים של OnePlus 3 בסערה בשיאו. כמובן, ה-Google Pixel מגיע גם עם EAS. עם ההבטחות לחיי סוללה משופרים וביצועים טובים יותר, מה הקאץ'?
Energy Aware Scheduling אינו פשוט מכיוון שהוא אינו אוניברסלי לכל מכשיר כמו CFS או HMP. EAS דורש הבנה של המעבד עליו הוא פועל, בהתבסס על מודל אנרגיה. מודלים אנרגטיים אלה מיוצרים על ידי צוותי מהנדסים הבודקים ופועלים ללא הרף כדי לתת ביצועים אופטימליים. מכיוון ש-Snapdragon 820 ו-821 זהים בעצם, גרעינים מותאמים אישית ב-OnePlus 3 משתמשים במודל האנרגיה של Google Pixel. מכשירים עם Snapdragon 845 יכולים להשתמש ב-EAS, ו-OnePlus 6 עושה זאת במידה מסוימת. זה לא מכוון כמו מכשיר Google Pixel, אבל הוא עושה את העבודה. הנה דוגמה כיצד, למרות של-OnePlus 6 יש מעבד טוב יותר עם EAS, ה-Pixel 2 XL עדיין מנצח אותו בצורה חלקה. שתי התמונות הללו נלקחו מהתמונות שלנו סקירה מכוונת מהירות של ה-OnePlus 6.
אם אתה מתקשה להבין את הגרפים, אתה יכול להסתכל בתמונה למטה לקבלת הדרכה. כל דבר החורג מהקו הירוק מעיד על נפילת פריימים ובמקרים הגרועים ביותר, גמגום מורגש.
הטמעת OnePlus 6 של EAS מעניינת, מכיוון שהיא לא נראית כיישום מלא כמו שאתה מוצא ב-Google Pixel עם אותו SoC. גם מתכוונני המתזמן אינם הגיוניים במיוחד, אז זה כנראה מסביר מדוע זה לא יעיל בביצועים כפי שהיית מצפה. זה שמרני ביותר בצריכת החשמל, כאשר המערכת נותנת עדיפות לליבות ההספק הנמוכות עבור רוב העבודה.
Tunables הם פשוט קבוצה של פרמטרים המועברים למושל ה-CPU, מה שמשנה את האופן שבו המושל מגיב למצבים מסוימים מבחינת תדירות. לאחר מכן מתזמן מחליט היכן הוא מציב משימות על מעבדים שונים. מכשירי הכוונון של ה-OnePlus 6 מוגדרים לתעדף עבודה על ליבות בעלות הספק נמוך. זה גם לא עוזר שלגוגל פיקסל 2 יש כמות עצומה של חיזוק קלט, ושומר על כל 8 הליבות באינטרנט כל הזמן. גוגל משתמשת גם ב-an איזון להפריע מה שעוזר להסיר נפילות מסגרת ולשפר את הביצועים.
אז איך EAS עובד? למה זה כל כך יעיל רק בתנאים מסוימים?
Energy Aware Scheduling מציג את הצורך להשתמש במודל אנרגיה, וכאמור לעיל דורש הרבה בדיקות ועבודה כדי להפוך אותו למושלם. EAS מנסה לאחד שלושה חלקי ליבה שונים של הגרעין שכולם פועלים באופן עצמאי, ומודל האנרגיה עוזר לאחד אותם.
- מתזמן לינוקס (CFS, שהוזכר לעיל)
- Linux cpuidle
- Linux cpufreq
איחוד כל 3 החלקים תחת המתזמן וחישובם יחד נותן פוטנציאל לחיסכון באנרגיה, שכן חישובם יחד מאפשר להם להיות יעילים ככל האפשר. CPUIdle מנסה להחליט מתי המעבד צריך לעבור למצב סרק, בעוד CPUFreq מנסה להחליט מתי להגביר או להוריד את המעבד. לשני המודולים הללו יש את המטרה העיקרית של חיסכון באנרגיה. לא רק זה, לאחר מכן הוא מחלק תהליכים לארבע קבוצות cgroups, שהם אפליקציה מובילה, רקע מערכת, קדמה ורקע. משימות שאמורות לעבור עיבוד ממוקמות באחת מהקטגוריות הללו, ואז הקטגוריה מקבלת כוח CPU והעבודה מואצלת על ליבות CPU שונות. האפליקציה העליונה היא העדיפות הגבוהה ביותר של השלמה, ואחריה קדמה, רקע ולאחר מכן רקע מערכת. לרקע מבחינה טכנית יש אותה עדיפות כמו רקע מערכת, אבל לרקע מערכת יש בדרך כלל גם גישה ליותר ליבות קטנות. למעשה, Energy Aware Scheduling לוקח חלקים הליבה של ליבת לינוקס ומאחד את הכל לתהליך אחד.
כאשר מעירים את המכשיר, EAS יבחר את הליבה במצב הסרק הרדוד ביותר, תוך מזעור האנרגיה הדרושה להעיר את המכשיר. זה עוזר להפחית את הכוח הנדרש בשימוש במכשיר, מכיוון שהוא לא יעיר את האשכול הגדול אם אין צורך בכך. מעקב אחר עומסים הוא גם חלק מכריע ביותר של EAS, ויש שתי אפשרויות. "מעקב עומס לפי ישות" (PELT) משמש בדרך כלל למעקב אחר עומס, המידע משמש לאחר מכן כדי להחליט על תדרים וכיצד להאציל משימות על פני המעבד. ניתן להשתמש גם ב-"Window-Assisted Load Tracking" (WALT), וזה מה שנמצא בשימוש ב-Google Pixel. EAS ROMs רבים בפורומים שלנו, כגון VertexOS, בוחרים להשתמש ב-WALT. ROMs רבים ישחררו שתי גרסאות של הקרנל עם WALT או PELT, כך שהמשתמש יחליט. WALT פרוץ יותר, עם פסגות גבוהות בתדר המעבד בעוד PELT מנסה להישאר עקבי יותר. מעקב העומס לא משפיע למעשה על תדירות המעבד, הוא רק אומר למערכת מה השימוש במעבד. שימוש גבוה יותר ב-CPU דורש תדר גבוה יותר ולכן תכונה עקבית של PELT היא שהוא גורם לתדר ה-CPU לעלות או לרדת לאט. PELT אכן נוטה לסטות לכיוון דיווח עומס מעבד גבוה יותר, כך שהוא עשוי לספק ביצועים גבוהים יותר בעלות סוללה גבוהה יותר. אף אחד לא באמת יכול לומר בשלב זה איזו מערכת מעקב עומס טובה יותר, עם זאת, מכיוון ששתי שיטות מעקב העומס עוברות תיקון ומשכללות ללא הרף.
כך או כך, ברור שללא קשר לשיטת מעקב העומס המשמשת, יש עלייה ביעילות. במקום רק לעבד משימות בכל מעבד, המשימה מנותחת ומוערכת את כמות האנרגיה הנדרשת להפעלתה. מיקום משימות חכם זה אומר שהמשימות יושלמו בצורה הרבה יותר יעילה ובמקביל הופכת את המערכת למהירה יותר כולה. EAS עוסק בקבלת ממשק המשתמש החלק ביותר האפשרי עם צריכת חשמל מינימלית. כאן נכנסים לתמונה רכיבים חיצוניים אחרים כגון schedtune.
Schedtune מוגדר בכל cgroup על ידי שני tunables אשר מבטיחים שליטה עדינה יותר על המשימות שיש להשלים. זה לא שולט רק בפיזור המשימות על פני מספר מעבדים, אלא גם אם יש לנפח את העומס הנתפס על מנת להבטיח שמשימות רגישות לזמן יושלמו מהר יותר. בדרך זו, יישומים ושירותים בחזית שהמשתמש משתמש בהם לא יאטו ויגרמו לבעיות ביצועים מיותרות.
בעוד שתזמון מודע לאנרגיה הוא הדבר הגדול הבא, אפשר גם לטעון שהוא כבר כאן וכבר היה זה זמן מה. עם יותר ויותר מכשירים שמגיעים למיינסטרים עם Energy Aware Scheduling, עידן חדש של יעילות עיבוד נייד כאן.
היתרונות והחסרונות של Round-Robin, CFS, HMP ו-EAS
אמנם כישורי הגרפיקה שלי הם פחות נמוכים, אבל זרקתי תמונה שאמורה לסכם מה היתרונות והחסרונות של כל אחד מהמתזמנים האלה.
אני רוצה להביע תודה מיוחדת לתורם המוכר XDA מוסטפא ואאל שההסברים שלו על היבטים שונים של EAS סייעו מאוד בהפיכת מאמר זה לאפשרי. אני גם רוצה להודות למפתח מוכר ל-XDA יהושע, מפתח מוכר XDA Render Broken ו מוסטפא וואאל על הכתיבה שלו על EAS. לאלו מכם שמצאו עניין בחלקים הקשורים ל-EAS, ל-Linaro יש הרבה תיעוד על EAS שתוכלו לקרוא.