Как EAS помогает сделать Google Pixel самым быстрым телефоном Android

Давным-давно, когда Linux был всего лишь идеей в голове Линуса Торвальдса, процессоры были одноядерными объектами, которым требовалось огромное количество энергии при небольшой мощности. Первый коммерчески доступный процессор Intel 4004 работал с тактовой частотой 740 кГц на одном ядре. Тогда не было необходимости в планировщике нагрузки. Планирование нагрузки было зарезервировано для двухъядерных «гигантов», таких как IBM Power 4, который появился несколько десятилетий спустя. Они работали на чудовищных частотах от 1,1 до 1,9 ГГц, и для правильного использования этих ядер требовались программы и система. Как мы пришли от этих машин к программным алгоритмам, использующим несколько ядер? Возможно, вы уже слышали об Energy Aware Scheduling (EAS) на наших форумах. Это одна из причин, почему смартфоны Google Pixel работают так хорошо. Что такого замечательного в EAS и как мы вообще дошли до этого? Прежде чем мы сможем это объяснить, нам нужно поговорить о планировщиках загрузки Linux.

---

Эволюция планировщиков загрузки Linux

Круговое планирование

Циклическая обработка — это простая концепция для объяснения и понимания, и еще более простая для понимания ее недостатков. В циклическом порядке используется разделение времени для распределения времени для каждого процесса. Предположим, на нашем компьютере запущено четыре процесса.

• Процесс А
• Процесс Б
• Процесс С
• Процесс Д

Теперь давайте поработаем с циклическим планировщиком. Мы выделим 100 миллисекунд (квант времени) каждому процессу, прежде чем перейти к следующему. Это означает, что процессу A может потребоваться 100 миллисекунд на обработку, затем он переходит к процессу B и так далее. Если работа приложения занимает 250 миллисекунд, ему придется пройти этот процесс 3 раза, чтобы завершить свою работу! Теперь масштабируйте это по разным ядрам, чтобы процессы A и B были выделены ядру 1, а процессы C и D — ядру 2. Это было заменено планированием O(n) (которое напоминало циклический алгоритм, но с использованием эпох и возможностью динамического распределения время), затем планирование O(1) (минимизация накладных расходов, неограниченная поддержка процессов), а затем, наконец, полностью честный планировщик. (КФС). CFS был объединен с ядром Linux версии 2.6.23 в октябре 2007 года. С тех пор он был переработан и до сих пор является планировщиком по умолчанию в системах Linux.

Полностью честный планировщик

Планировщик Completely Fair существует в Android с момента его создания и используется на небольших платформах. МАЛЕНЬКИЕ устройства. Он использует интеллектуальный алгоритм для определения порядка обработки, выделенного времени и т. д. Это пример рабочей реализации хорошо изученного алгоритма планирования, называемого «взвешенная справедливая организация очереди». В основном это направлено на обеспечение приоритета системным процессам и другим высокоприоритетным процессам, выполняемым на компьютере. машина. Если бы он работал на большом уровне. МАЛЕНЬКОЕ устройство, все ядра будут восприниматься как равные. Это плохо, поскольку ядра с низким энергопотреблением могут быть вынуждены запускать интенсивные приложения или, что еще хуже, может произойти обратное. Декодирование для прослушивания музыки может выполняться на большом ядре, например, без необходимости повышая энергопотребление. Вот почему нам нужен новый планировщик для big. LITTLE, который действительно может распознавать и эффективно использовать разницу в ядрах. Именно здесь на помощь приходит гетерогенная многопроцессорная обработка (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 в виде ядер, таких как РендерЗенит и ПЗУ, такие как 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 также использует балансировщик прерываний что помогает устранить пропадание кадров и повысить производительность.

Так как же работает EAS? Почему он так эффективен только в определенных условиях?

Energy Aware Scheduling требует использования энергетической модели и, как упоминалось выше, требует большого количества испытаний и работы, чтобы сделать ее идеальной. EAS пытается объединить три различные основные части ядра, которые действуют независимо, и энергетическая модель помогает их объединить.

• Планировщик Linux (CFS, упомянутый выше)
• Процессор Linux
• Процессор Linux

Объединение всех 3 частей под планировщиком и их совместный расчет дает потенциал для энергосбережения, так как совместный расчет позволяет им быть максимально эффективными. CPUIdle пытается решить, когда ЦП должен перейти в режим ожидания, а CPUFreq пытается решить, когда следует увеличить или уменьшить нагрузку на ЦП. Оба этих модуля имеют основную цель экономии энергии. Мало того, он затем классифицирует процессы на четыре контрольные группы: верхнее приложение, системный фон, передний план и фон. Задачи, подлежащие обработке, помещаются в одну из этих категорий, затем этой категории присваивается мощность ЦП, а работа делегируется различным ядрам ЦП. top-app имеет наивысший приоритет завершения, за ним следуют передний план, фон и затем системный фон. Технически фон имеет тот же приоритет, что и system-background, но system-background обычно также имеет доступ к большему количеству маленьких ядер. По сути, Energy Aware Scheduling берет основные части ядра Linux и объединяет их все в один процесс.

При выводе устройства из режима ожидания EAS выбирает ядро ​​в состоянии наименьшего простоя, сводя к минимуму энергию, необходимую для пробуждения устройства. Это помогает снизить потребляемую мощность при использовании устройства, поскольку оно не будет разбудить большой кластер, если в этом нет необходимости. Отслеживание нагрузки также является чрезвычайно важной частью EAS, и здесь есть два варианта. «Отслеживание нагрузки на объект» (PELT) обычно используется для отслеживания нагрузки, затем информация используется для определения частоты и способа делегирования задач по ЦП. Также можно использовать «Отслеживание загрузки с помощью окна» (WALT), и именно это используется в Google Pixel. Многие EAS-ROM на наших форумах, такие как VertexOS, предпочитают использовать WALT. Многие ПЗУ выпускают две версии ядра с WALT или PELT, поэтому решать пользователю. WALT работает более скачкообразно, с высокими пиками частоты процессора, в то время как PELT пытается оставаться более последовательным. Трекер нагрузки на самом деле не влияет на частоту процессора, он просто сообщает системе, на каком уровне используется процессор. Более высокая загрузка ЦП требует более высокой частоты, поэтому отличительной чертой PELT является то, что он вызывает медленное повышение или понижение частоты ЦП. PELT имеет тенденцию отклоняться в сторону отчетов о более высокой загрузке ЦП, поэтому он может обеспечить более высокую производительность при более высоких затратах на батарею. Однако на данный момент никто не может точно сказать, какая система отслеживания нагрузки лучше, поскольку оба метода отслеживания нагрузки постоянно обновляются и совершенствуются.

В любом случае очевидно, что независимо от используемого метода отслеживания нагрузки наблюдается повышение эффективности. Вместо того, чтобы просто обрабатывать задачи на любом процессоре, задача анализируется и оценивается количество энергии, необходимое для ее выполнения. Такое продуманное размещение задач означает, что задачи выполняются гораздо эффективнее, а также ускоряется работа системы в целом. Целью EAS является получение максимально плавного пользовательского интерфейса с минимальным энергопотреблением. Здесь в игру вступают другие внешние компоненты, такие как schedtune.

Schedtune определяется в каждой контрольной группе двумя параметрами, которые обеспечивают более точный контроль над задачами, которые необходимо выполнить. Он не только контролирует распределение задач по нескольким процессорам, но также определяет, следует ли увеличивать воспринимаемую нагрузку, чтобы обеспечить более быстрое выполнение срочных задач. Таким образом, приоритетные приложения и службы, которыми пользуется пользователь, не будут замедляться и вызывать ненужные проблемы с производительностью.

Хотя планирование с учетом энергопотребления является следующим большим достижением, можно также утверждать, что оно уже здесь и существует уже некоторое время. Поскольку все больше и больше устройств становятся популярными благодаря Energy Aware Scheduling, наступает новая эра эффективности мобильной обработки данных.

Плюсы и минусы Round-Robin, CFS, HMP и EAS

Хотя мои графические навыки не на должном уровне, я собрал изображение, которое должно суммировать плюсы и минусы каждого из этих планировщиков.

---

Я хотел бы выразить особую благодарность признанному участнику XDA. Мостафа Ваэль чьи объяснения различных аспектов EAS во многом помогли написанию этой статьи. Я также хотел бы поблагодарить признанного разработчика XDA. веселый, признанный разработчик XDA RenderBroken и Мостафа Ваэль за рецензию на EAS. Для тех из вас, кто заинтересовался деталями, связанными с EAS, у Linaro есть много документации по EAS, которую вы можете прочитать.