Мощность — это общий объем некоторого ресурса (ЦП, ГП и т. д.), которым устройство обладает в течение определенного периода времени. На этой странице описывается, как выявлять и устранять проблемы джанкирования, связанные с емкостью.
Губернатор медленно реагирует
Чтобы избежать рывков, регулятор частоты ЦП должен быстро реагировать на скачкообразные рабочие нагрузки. Большинство приложений пользовательского интерфейса следуют одному и тому же базовому шаблону:
- Пользователь читает экран.
- Пользователь касается экрана: нажимает кнопку, прокручивает и т. д.
- Экран прокручивается, изменяет активность или каким-то образом анимируется в ответ на ввод.
- Система останавливается при отображении нового содержимого.
- Пользователь возвращается к чтению экрана.
Устройства Pixel и Nexus реализуют ускорение касания, чтобы изменить поведение регулятора частоты процессора (и планировщика) при касании. Чтобы избежать медленного перехода к высокой тактовой частоте (что может привести к пропуску кадров устройства при касании), Touch Boost обычно устанавливает минимальную частоту на ЦП, чтобы гарантировать, что при касании будет доступна большая мощность ЦП. Пол длится некоторое время после прикосновения (обычно около двух секунд).
Pixel также использует контрольную группу schedtune, предоставленную Energy Aware Scheduling (EAS), в качестве дополнительного сигнала ускорения касания: основные приложения получают дополнительный вес через schedtune, чтобы гарантировать, что они получают достаточную мощность ЦП для быстрой работы. Nexus 5X и 6P имеют гораздо больший разрыв в производительности между малым и большим кластерами ЦП (A53 и A57 соответственно), чем Pixel с процессором Kryo. Мы обнаружили, что небольшого кластера ЦП не всегда достаточно для плавного рендеринга пользовательского интерфейса, особенно с учетом других источников джиттера на устройстве.
Соответственно, на Nexus 5X и 6P ускорение касания изменяет поведение планировщика, повышая вероятность того, что приложения переднего плана будут перемещаться на большие ядра (это концептуально похоже на минимальную частоту процессора). Без изменения планировщика, повышающего вероятность перемещения приложений переднего плана на большой кластер ЦП, у приложений переднего плана может быть недостаточно мощности ЦП для рендеринга, пока планировщик не решит сбалансировать нагрузку потока на большое ядро ЦП. Изменяя поведение планировщика во время Touch Boost, поток пользовательского интерфейса с большей вероятностью сразу же запускается на большом ядре и избегает рывков, не заставляя его всегда работать на большом ядре, что может серьезно повлиять на энергопотребление.
Термическое дросселирование
Термическое регулирование происходит, когда устройство должно снизить общую тепловую мощность, обычно выполняемую за счет уменьшения тактовой частоты ЦП, графического процессора и DRAM. Неудивительно, что это часто приводит к зависаниям, поскольку система больше не может обеспечивать достаточную мощность для рендеринга в течение заданного временного интервала. Единственный способ избежать теплового дросселирования — использовать меньше энергии. Существует не так много способов сделать это, но, основываясь на нашем опыте с предыдущими SOC, у нас есть несколько рекомендаций для поставщиков систем.
Во-первых, при создании нового SOC с гетерогенными архитектурами ЦП убедитесь, что кривые производительности/Вт кластеров ЦП перекрываются. Кривая общей производительности/Вт для всего процессора должна представлять собой непрерывную линию. Разрывы в кривой производительность/Вт вынуждают планировщик и регулятор частоты угадывать, что нужно рабочей нагрузке; чтобы предотвратить рывки, планировщик и регулятор частоты ошибаются, предоставляя рабочей нагрузке больше мощности, чем она требует. Это приводит к трате слишком большого количества энергии, что способствует тепловому дросселированию.
Представьте себе гипотетический SOC с двумя кластерами ЦП:
- Кластер 1, маленький кластер, может потреблять от 100 до 300 мВт и набирает 100-300 баллов в тесте пропускной способности в зависимости от тактовой частоты.
- Кластер 2, большой кластер, может расходовать от 1000 до 1600 мВт и набрать от 800 до 1200 баллов в том же тесте пропускной способности в зависимости от тактовой частоты.
В этом тесте чем выше результат, тем быстрее. Хотя не более желательно, чем медленнее, быстрее == большее энергопотребление.
Если планировщик полагает, что рабочая нагрузка пользовательского интерфейса потребует эквивалента 310 баллов в этом тесте пропускной способности, его лучший способ избежать рывков — запустить большой кластер на самой низкой частоте, что приведет к потере значительной мощности. (Это зависит от поведения процессора и гонки на простои; SOC с непрерывными кривыми производительности/Вт легче оптимизировать.)
Во-вторых, используйте процессоры. Убедитесь, что вы включили процессорные наборы в своем ядре и в BoardConfig.mk . Вы также должны настроить фактические назначения процессорных наборов в файле init.rc для вашего устройства. Некоторые поставщики отключают это в своих BSP в надежде, что они смогут использовать другие подсказки для влияния на поведение планировщика; мы чувствуем, что это не имеет смысла. cpusets полезны для обеспечения балансировки нагрузки между ЦП таким образом, который отражает то, что пользователь фактически делает на устройстве.
ActivityManager назначает приложения различным процессорным наборам в зависимости от относительной важности этих приложений (верхний, передний план, фон), при этом более важные приложения получают больший доступ к ядрам ЦП. Это помогает обеспечить качество обслуживания для приложений переднего плана и основных приложений.
Наборы процессоров полезны для однородных конфигураций ЦП, но не следует поставлять устройство с гетерогенной конфигурацией ЦП без включенных наборов ЦП. Nexus 6P — хорошая модель использования процессорных наборов в гетерогенных конфигурациях ЦП; используйте это как основу для конфигурации вашего собственного устройства.
Процессорные наборы также обеспечивают преимущества в энергопотреблении, гарантируя, что фоновые потоки, которые не являются критичными для производительности, никогда не распределяются по нагрузке на большие ядра ЦП, где они могут расходовать значительно больше энергии без какой-либо выгоды, воспринимаемой пользователем. Это также может помочь избежать теплового дросселирования. Хотя тепловое регулирование является проблемой емкости, улучшения джиттера оказывают огромное влияние на производительность пользовательского интерфейса при тепловом регулировании. Поскольку система будет работать ближе к своей способности отображать 60 кадров в секунду, требуется меньше дрожания, чтобы вызвать пропущенный кадр.