Смартфоните Google Pixel са сред най-бързите Android телефони на пазара. Energy Aware Scheduling (EAS) отчасти е причината телефонът да работи толкова гладко.
Далеч в миналото, когато Linux беше само идея в съзнанието на Линус Торвалдс, процесорите бяха едноядрени обекти, които изискваха огромно количество енергия срещу малко мощност. Първият достъпен в търговската мрежа процесор, Intel 4004, работеше с тактова честота от 740 kHz на едно ядро. Тогава нямаше нужда от планировчик на натоварването. Графикът на натоварването беше запазен за двуядрените "гиганти" като IBM Power 4, който се появи няколко десетилетия по-късно. Те работеха на зверски 1,1GHz до 1,9GHz и изискваха програми и система да използват тези ядра правилно. Как стигнахме от тези машини до софтуерни алгоритми, които използват множество ядра? Може би сте чували за енергийно ориентирано планиране (EAS) в нашите форуми преди. Това е част от причината, поради която смартфоните Google Pixel се представят толкова добре. Какво е толкова страхотно в EAS и как изобщо стигнахме дотук? Преди да можем да обясним това, трябва да поговорим за програматорите за зареждане на Linux.
Еволюцията на програматорите за зареждане на Linux
График по кръгов режим
Кръговата обработка е проста концепция за обяснение и разбиране и още по-проста за разбиране на нейните недостатъци. Round-robin използва разделяне на времето, за да разпредели време за всеки процес. Да приемем, че имаме четири процеса, работещи на нашия компютър.
- Процес А
- Процес Б
- Процес C
- Процес D
Сега нека свършим работата на кръговия планировчик. Ще разпределим 100 милисекунди (отрязване на времето) за всеки процес, преди да преминем към следващия. Това означава, че процес A може да отнеме 100 милисекунди, за да извърши своята обработка, след което се премества към процес B и така нататък. Ако работата на едно приложение отнема 250 милисекунди, то ще трябва да премине през този процес 3 пъти, само за да завърши работата си! Сега мащабирайте това в различни ядра, така че процес A и процес B да бъдат разпределени към ядро 1, а процес C и процес D да са разпределени към ядро 2. Това беше заменено от O(n) планиране (което беше като кръгов режим, но използваше епохи и позволяваше динамично разпределение на време), след това O(1) планиране (минимизирани режийни разходи, неограничена поддръжка на процеси), след това накрая Напълно справедлив планировчик (CFS). CFS беше обединен с ядрото на Linux версия 2.6.23 през октомври 2007 г. Оттогава той е основно преработен и все още е планировчикът по подразбиране в Linux системите.
Напълно справедлив планировчик
The Completely Fair Scheduler съществува в Android от самото му създаване и се използва на не-големи. МАЛКИ устройства. Той използва интелигентен алгоритъм за определяне на реда на обработка, разпределеното време и т.н. Това е пример за работеща реализация на добре проучения алгоритъм за планиране, наречен "претеглено справедливо опашка". Това основно се фокусира върху предоставянето на приоритет на системните процеси и други процеси с висок приоритет, изпълнявани на машина. Ако трябваше да работи на голям. МАЛКО устройство, всички ядра ще се възприемат като равни. Това е лошо, тъй като ядрата с ниска мощност могат да бъдат принудени да изпълняват интензивни приложения или дори по-лошо, може да се случи обратното. Декодирането за слушане на музика може да се извърши на голямото ядро, например, увеличавайки ненужно консумацията на енергия. Ето защо се нуждаем от нов планировчик за големи. LITTLE, който действително може да разпознае и използва разликата в ядрата по енергийно ефективен начин. Това е мястото, където Heterogeneous Multi-Processing (HMP) идва, стандартният планировчик на натоварване, който повечето телефони с Android работят сега.
Хетерогенна мултипроцесорна обработка
Това е стандартният планировчик на натоварване за всеки голям. МАЛКО устройство, пуснато през последните години, различно от Google Pixel. HMP използва голямото. LITTLE архитектура, делегираща нисък приоритет, по-малко интензивна работа на малките ядра, които консумират по-малко енергия. 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 и ROM като 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.
Ако имате проблеми с разбирането на графиките, можете да погледнете изображението по-долу за насоки. Всичко, което надвишава зелената линия, показва пропуснати кадри и в най-лошите случаи забележимо заекване.
Имплементацията на EAS в OnePlus 6 е интересна, тъй като не изглежда да е пълноценна реализация, каквато бихте намерили в Google Pixel със същия SoC. Настройките на планировчика също нямат много смисъл, така че това вероятно обяснява защо не е толкова ефективен в производителността, колкото бихте очаквали. Той е изключително консервативен по отношение на консумацията на енергия, като системата дава приоритет на ядрата с ниска мощност за по-голямата част от работата.
Регулируемите са просто набор от параметри, които се предават на регулатора на процесора, което променя начина, по който регулаторът реагира на определени ситуации по отношение на честотата. След това планировчикът решава къде поставя задачите на различни процесори. Настройките на OnePlus 6 са настроени да приоритизират работата върху ядра с ниска мощност. Също така не помага, че Google Pixel 2 има огромно количество входно усилване, поддържайки всичките 8 ядра онлайн през цялото време. Google също използва an балансьор на прекъсвания което помага да се премахнат паданията на рамката и да се подобри производителността.
И така, как работи EAS? Защо е толкова ефективен само при определени условия?
Energy Aware Scheduling въвежда необходимостта от използване на енергиен модел и, както бе споменато по-горе, изисква много тестове и работа, за да стане перфектен. EAS се опитва да обедини три различни основни части на ядрото, които действат независимо, а енергийният модел помага за тяхното обединяване.
- Планировчик на Linux (CFS, споменат по-горе)
- Linux cpuidle
- Linux cpufreq
Обединяването на всичките 3 части в планировчика и изчисляването им заедно дава потенциал за спестяване на енергия, тъй като изчисляването им заедно им позволява да бъдат възможно най-ефективни. CPUIdle се опитва да реши кога процесорът трябва да премине в режим на неактивност, докато CPUFreq се опитва да реши кога да увеличи или намали процесора. И двата модула имат за основна цел спестяване на енергия. Не само това, след това той категоризира процесите в четири cgroups, като топ-приложение, системен фон, преден план и фон. Задачите, които трябва да бъдат обработени, се поставят в една от тези категории, след което на категорията се дава мощност на процесора и работата се делегира на различни ядра на процесора. top-app е най-високият приоритет на завършване, следван от преден план, фон и след това системен фон. Технически фонът има същия приоритет като системния фон, но системният фон обикновено също има достъп до повече малки ядра. На практика Energy Aware Scheduling взема основните части от ядрото на Linux и ги обединява в един процес.
Когато събужда устройството, EAS ще избере ядрото в най-плиткото състояние на неактивност, минимизирайки енергията, необходима за събуждане на устройството. Това помага да се намали необходимата мощност при използване на устройството, тъй като няма да събуди големия клъстер, ако не е необходимо. Проследяването на натоварването също е изключително важна част от EAS и има две опции. „Проследяване на натоварването по обект“ (PELT) обикновено се използва за проследяване на натоварването, след което информацията се използва за определяне на честотите и как да се делегират задачи в процесора. „Window-Assisted Load Tracking“ (WALT) също може да се използва и е това, което се използва в Google Pixel. Много EAS ROM на нашите форуми, като VertexOS, избират да използват WALT. Много ROM ще пуснат две версии на ядрото с WALT или PELT, така че зависи от потребителя да реши. WALT е по-бурен, с високи пикове в честотата на процесора, докато PELT се опитва да остане по-последователен. Инструментът за проследяване на натоварването всъщност не влияе на честотата на процесора, той просто казва на системата какво е използването на процесора. По-високото използване на процесора изисква по-висока честота и следователно последователна характеристика на PELT е, че кара честотата на процесора да нараства или намалява бавно. PELT има тенденция да се отклонява към отчитане на по-високо натоварване на процесора, така че може да осигури по-висока производителност при по-висока цена на батерията. Никой обаче не може наистина да каже в този момент коя система за проследяване на натоварването е по-добра, тъй като и двата метода за проследяване на натоварването непрекъснато се коригират и усъвършенстват.
Така или иначе, очевидно е, че независимо от използвания метод за проследяване на натоварването, има увеличение на ефективността. Вместо просто да обработва задачи на който и да е процесор, задачата се анализира и се оценява количеството енергия, необходимо за нейното изпълнение. Това интелигентно разположение на задачите означава, че задачите се изпълняват по много по-ефективен начин, като същевременно прави системата по-бърза като цяло. EAS цели получаването на възможно най-плавния потребителски интерфейс с минимално потребление на енергия. Това е мястото, където други външни компоненти като schedtune влизат в действие.
Schedtune се дефинира във всяка cgroup от две настройки, които осигуряват по-фин контрол върху задачите, които трябва да бъдат изпълнени. Той не само контролира разпределението на задачите върху множество процесори, но също и дали възприеманото натоварване трябва да бъде завишено, за да се гарантира, че чувствителните към времето задачи се изпълняват по-бързо. По този начин приложенията и услугите на преден план, от които потребителят се възползва, няма да се забавят и да причинят ненужни проблеми с производителността.
Докато Energy Aware Scheduling е следващото голямо нещо, може да се твърди, че вече е тук и е от известно време. С все повече и повече устройства, навлизащи в мейнстрийма с Energy Aware Scheduling, новата ера на ефективността на мобилната обработка е тук.
Плюсовете и минусите на Round-Robin, CFS, HMP и EAS
Въпреки че моите графични умения са под номинала, събрах изображение, което трябва да обобщи какви са плюсовете и минусите на всеки от тези планировчици.
Бих искал да изкажа специална благодарност на XDA Recognized Contributor Мостафа Ваел чиито обяснения на различни аспекти на EAS значително помогнаха тази статия да стане възможна. Бих искал също да благодаря на XDA Recognized Developer joshuous, XDA признат разработчик RenderBroken и Мостафа Ваел за неговия коментар за EAS. За тези от вас, които се интересуват от свързаните с EAS части, Linaro има много документация за EAS, която можете да прочетете.