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