cccarbon @ 07.09.2016, 22:17
Я тут расписывал свои представления о говерноре и бусте, они не верные.
Пишу здесь, потому что, во-первых, это может быть полезно всем, кто настраивает скрипты, а, во-вторых, кто-то мог успеть прочитать то, что я вчера ошибочно написал и где-то там что-то запомнить неправильное. Я взял секундомер, зафиксировал большие ядра на 633 МГц, чтобы можно было спокойно работать, и начал ставить в говернор значения, которые можно оценить вручную (успеть отследить секундомером), т.е. речь идёт о 5, 10, 20 секундах — таких значениях. Проверялась взаимосвязь между таймерами timer_rate, min_sample_time (по идее, above_hispeed_delay и max_freq_hysteresis работают аналогично) и input_boost_ms.
Мини-справка:
timer_rate — периодичность с которой говернор проверяет нагрузку и меняет частоту;
min_sample_time — минимальное время пребывания на очередной частоте, перед её снижением;
above_hispeed_delay — минимальное время пребывания на очередной частоте, перед её повышением;
max_freq_hysteresis — минимальное время пребывания на максимальной частоте перед её снижением;
input_boost_ms — минимальная длительность работы на повышенной частоте (input_boost_freq) при прикосновении к экрану (input_boost).
Итак, что прояснилось:
1. Нагрузка оценивается непосредственно в момент срабатывания таймера (=тик) говернора timer_rate. Например, timer_rate у нас 10 секунд. 9,99 секунд у нас нагрузка была 100%, на 10 с 0% — частота меняться не будет.
2. Частота меняется только по тикам говернора (если не считать роста по input_boost). Длительность min_sample_time, above_hispeed_delay и max_freq_hysteresis задают минимальную длительность. Если их время заканчивается между тиками говернора, частота изменится только во время очередного тика.
Например, timer_rate 10 секунд. Min_sample_time у нас 5 с. Во время очередного тика выросла частота и нагрузка упала. Через 5 с — ничего не произойдёт. Через 10 с — отработает говернор и, если нужно, частота упадёт. Другой пример, min_sample_time у нас 11 с. 0 с — выросла частота и упала нагрузка, 10 с — говернор молчит (если нагрузка не выросла), 11 с — ничего не меняется, 20 с — вот теперь говернор может снизить частоту.
Важное замечание. Если поставить min_sample_time = timer_rate или очень близким к нему (там микросекунды!), скорее всего, переключение частот произойдёт уже только на следующем тике (timer_rate x2), так как есть задержка, обусловленная физическими характеристиками чипа (вероятно, в какой-то документации можно даже узнать точное число).
3. input_boost повышает частоту независимо от таймера говернора. Впрочем, это и так очевидно, в этом его смысл. А вот дальнейшим изменением частоты занимается говернор, а значит оно привязано к таймеру говернора.
Например, timer_rate у нас 10 с, input_boost_ms у нас 5 с. Мы коснулись экрана на второй секунде таймера говернора — частота выросла. Через 5 секунд (7 секунда таймера говернора) — ничего не поменяется. На 10 секунде отработает говернор и изменит частоту соответственно нагрузке.
UPD: С нагрузкой я промахнулся. Неправильно интерпретировал наблюдения. Я не понимаю до конца, как это работает. Вроде как используется статистика работы системы из /proc/stat, при этом, если процессор был в состоянии idle, то статистика учитывается только за очень короткий промежуток времени (чтобы сразу выдать адекватную производительность), а если процессор был под нагрузкой — то статистика с момента последнего изменения частоты. Причем нагрузка — опосредованный параметр. В статистике /proc/stat пишется время простоя процессора и время его занятости разными процессами.
Это важно, потому что нагрузка — всё-таки следствие статистики, т.е. определяет прошлое, а не настоящее. Да еще и с потенциально большой инерцией.
Сообщение отредактировал a5m - 12.09.16, 09:41