Смартфони Google Pixel є одними з найшвидших Android-телефонів на ринку. Планування з урахуванням енергоспоживання (EAS) частково є причиною такої гладкості телефону.
У далекому минулому, коли Linux був лише ідеєю в голові Лінуса Торвальдса, процесори були одноядерними об’єктами, які вимагали величезної кількості енергії за невелику потужність. Перший в історії комерційно доступний процесор Intel 4004 працював на одному ядрі з тактовою частотою 740 кГц. Тоді ще не було потреби в планувальнику навантаження. Планування завантаження було зарезервовано для двоядерних "гігантів", таких як IBM Power 4, який вийшов через кілька десятиліть. Вони працювали на жахливій частоті від 1,1 ГГц до 1,9 ГГц і потребували програм і системи для правильного використання цих ядер. Як ми дійшли від цих машин до програмних алгоритмів, які використовують кілька ядер? Можливо, на наших форумах ви вже чули про розклад з урахуванням енергії (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.
Повністю чесний планувальник
Планувальник Completely Fair існує в Android з моменту його створення та використовується на невеликих. МАЛЕНЬКІ пристрої. Він використовує інтелектуальний алгоритм для визначення порядку обробки, розподіленого часу тощо. Це приклад робочої реалізації добре вивченого алгоритму планування під назвою «зважена справедлива черга». Це в основному зосереджено на наданні пріоритету системним процесам та іншим високопріоритетним процесам, що виконуються на машина. Якби він мав працювати на великій. МАЛЕНЬКИЙ пристрій, усі ядра сприйматимуться як рівні. Це погано, оскільки ядра з низьким енергоспоживанням можуть бути змушені запускати інтенсивні програми, або, що ще гірше, може статися навпаки. Декодування для прослуховування музики можна зробити на великому ядрі, наприклад, збільшуючи енергоспоживання без потреби. Ось чому нам потрібен новий планувальник для великих. LITTLE, який дійсно може розпізнавати та використовувати різницю в ядрах енергоефективним способом. Ось тут і з’являється Heterogeneous Multi-Processing (HMP), стандартний планувальник завантаження, який зараз працює на більшості телефонів Android.
Гетерогенна багатопроцесорна обробка
Це стандартний планувальник завантаження для будь-якого великого. МАЛЕНЬКИЙ пристрій, випущений за останні роки, крім Google Pixel. HMP використовує великий. LITTLE архітектура, що делегує низький пріоритет, менш інтенсивну роботу маленьким ядрам, які споживають менше енергії. HMP є «безпечним», оскільки він знає, що має надходити до великих ядер, а що має надходити до маленьких ядер, не допускаючи помилок. Він просто працює та потребує набагато менше зусиль для налаштування на стороні розробки, ніж щось на кшталт EAS, про яке ми зараз поговоримо. HMP є лише розширенням CFS, щоб зробити його потужним.
HMP не робить припущень і не передбачає майбутні процеси. Це добре, але тому пристрій не може бути таким плавним, як ті, що працюють на EAS, і тому він споживає трохи більше батареї. Це, нарешті, підводить нас до Energy Aware Scheduling (EAS), за яким я твердо вірю, що це майбутнє в ПЗУ та розробці ядра, оскільки все більше OEM-виробників приймуть його.
Планування з урахуванням енергії
Energy Aware Scheduling (EAS) — наступна велика річ, про яку говорять користувачі на наших форумах. Якщо ви використовуєте OnePlus 3 (або Google Pixel, очевидно), ви точно чули про це на форумах. Він став популярним завдяки Qualcomm Snapdragon 845, тож якщо у вас є один із цих пристроїв, у вас уже є смартфон із підтримкою EAS. EAS у формі ядер, таких як RenderZenith і ПЗУ, наприклад VertexOS і PureFusion захопили форуми OnePlus 3 штурмом у його розквіті. Звичайно, Google Pixel також поставляється з EAS. З обіцянками покращеного терміну служби батареї та кращої продуктивності, у чому заковика?
Планування з урахуванням енергії не таке просте, оскільки воно не є універсальним для кожного пристрою, такого як 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 намагається вирішити, коли збільшити або зменшити ЦП. Основною метою обох цих модулів є енергозбереження. Крім того, він класифікує процеси за чотирма контрольними групами: головна програма, фонова система, передній план і фон. Завдання, які мають бути оброблені, розміщуються в одній із цих категорій, а потім цій категорії надається потужність ЦП, а робота делегується іншим ядрам ЦП. top-app має найвищий пріоритет завершення, за яким ідуть foreground, background, а потім system-background. Технічно фон має такий же пріоритет, як і системний фон, але системний фон зазвичай також має доступ до більшої кількості маленьких ядер. По суті, Energy Aware Scheduling бере основні частини ядра Linux і об’єднує все це в один процес.
Під час виведення пристрою з режиму сну EAS вибере ядро в стані очікування з найдрібнішим значенням, мінімізуючи енергію, необхідну для пробудження пристрою. Це допомагає зменшити необхідну потужність під час використання пристрою, оскільки він не виводить великий кластер з режиму сну, якщо йому це не потрібно. Відстеження навантаження також є надзвичайно важливою частиною EAS, і є два варіанти. "Відстеження навантаження за об'єктом" (PELT) зазвичай використовується для відстеження навантаження, потім інформація використовується для визначення частоти та способів делегування завдань між ЦП. «Відстеження завантаження за допомогою вікон» (WALT) також можна використовувати, і це те, що використовується на Google Pixel. Багато ПЗУ EAS на наших форумах, наприклад VertexOS, вибирають використання WALT. Багато ПЗУ випускають дві версії ядра з WALT або PELT, тому вирішувати користувачеві. WALT більш бурхливий, з високими піками частоти процесора, тоді як PELT намагається залишатися більш послідовним. Відстеження навантаження фактично не впливає на частоту ЦП, а лише повідомляє системі, яке використання ЦП. Більше використання ЦП вимагає більш високої частоти, тому послідовна риса PELT полягає в тому, що він змушує частоту ЦП повільно зростати або знижуватися. PELT, як правило, відхиляється від звітів про високе навантаження на процесор, тому може забезпечити вищу продуктивність за вищої вартості батареї. Однак на даний момент ніхто не може точно сказати, яка система відстеження навантаження краща, оскільки обидва методи відстеження навантаження постійно вдосконалюються та вдосконалюються.
У будь-якому випадку, очевидно, що, незалежно від використовуваного методу відстеження навантаження, ефективність підвищується. Замість того, щоб просто обробляти завдання на будь-якому процесорі, завдання аналізується та оцінюється кількість енергії, необхідної для його виконання. Це розумне розміщення завдань означає, що завдання виконуються набагато ефективніше, а також робить систему в цілому швидшою. EAS — це отримання максимально плавного інтерфейсу з мінімальним енергоспоживанням. Тут у гру вступають інші зовнішні компоненти, такі як Schedtune.
Schedtune визначається в кожній контрольній групі за допомогою двох параметрів, що забезпечують точніший контроль над завданнями, які потрібно виконати. Він не лише контролює розподіл завдань між кількома процесорами, але й те, чи має бути підвищене сприйняте навантаження, щоб гарантувати швидке виконання завдань, чутливих до часу. Таким чином, основні програми та служби, якими користується користувач, не сповільнюватимуть роботу та не спричинятимуть непотрібних проблем з продуктивністю.
Незважаючи на те, що планування з урахуванням енергії є наступною важливою технологією, можна стверджувати, що воно вже існує і існує деякий час. Оскільки все більше і більше пристроїв потрапляють у мейнстрім із технологією Energy Aware Scheduling, настає нова ера ефективності мобільної обробки.
Плюси та мінуси Round-Robin, CFS, HMP та EAS
Хоча мої навички роботи з графікою невисокі, я зібрав зображення, яке повинно підсумувати переваги та недоліки кожного з цих планувальників.
Я хотів би висловити особливу подяку визнаному учаснику XDA Мостафа Ваель чиї пояснення різних аспектів EAS значно допомогли зробити цю статтю можливою. Я також хотів би подякувати XDA Recognized Developer joshuous, визнаний розробник XDA RenderBroken і Мостафі Ваелю за його статті про EAS. Для тих із вас, хто зацікавився частинами, пов’язаними з EAS, Linaro має багато документації про EAS, яку ви можете прочитати.