Управление частотой процессора ноутбука в Linux
Уже давно стал замечать, что если смотреть видеоролики в интернете на нетбуке с процессором Intel Atom, они немного подтормаживают. Покопавшись в логах понял, что в это самое время загрузка процессора идет на 100%, а состояние процессора почему-то остается в режиме “энергосбережение”. То ли всему виной операционная система Linux, то ли сам Atom так себя ведет, непонятно.
Единственным решением, которое я увидел, это самостоятельно управлять режимами работы процессора, благо cpufrequtils – это позволяет делать.
В большинстве случаев у Вас уже должна стоять утилита cpufrequtils, но на всякий случай исполняем команду установки этого дела:
В cpufrequtils есть несколько готовых шаблонов работы процессора:
- performance – максимальное быстродействие;
- powersave – режим энергосбережения;
- ondemand – автоматический режим, при котором происходит изменение частоты процессора в зависимости от нагрузки (этот режим стоит по умолчанию);
- conservative – тоже самое как и ondemand, но менее агрессивно.
Возможно, есть где-нибудь в закоулках сайта Intel специальный модуль для ядра Linux, чтобы мой процессор умно переключал эти режимы, но искать мне его лень. Если кто-нибудь это уже делал, то было бы неплохо об этом рассказать в комментариях. Лично я просто вручную переключаю эти режимы консольными командами.
Вот, к примеру, если нужно переключить процессор в максимальное быстродействие:
Если в режим энергосбережения, то эта команда:
Как делаю это я?
У меня, как я уже сказал, Intel Atom (нетбук, который я купил в интернет-магазине) и он почему-то не переводит режимы приведенными выше командами. Мне приходится переключать режимы для каждого ядра в отдельности.
Так как у моего процессора 4 ядра, то делаю я это так:
быстродействие:
Из этих двух команд я создал 2 скрипта и “повешал” на сочетание клавиш Ctrl+F8 и Ctrl+F9. Теперь в зависимости от потребностей я могу легко менять частоту процессора.
P.S. Для того, чтобы при переключении не выскакивала консоль (терминал) необходимо вместо sudo использовать gksudo. Это графический интерфейс для ввода пароля.
И че, видать результат?! А как это понять?! Если включен режим энергосбережения тогда CPU почему до 100%? Мне кажется это все такое самовнушение. Прошу вас ответить увидели ли вы положительный результат от вкл выкл данного режима?!
Конечно есть. Производительность, как и шум вентилятора стали максимальны 😉
Посмотреть текущую работу процессора можно командой cpufreq-info
Балин, тоже счастливый обладатель подобного недоноута, в настоящее время использую его как роутер 🙂 Статья полезная попробуем применить на практике.
Политика управления частотой процессора «ondemand» и iowait в Ubuntu
В современных версиях Ubuntu по умолчанию включена политика управления частотой процессора «ondemand». Эта штука весьма полезна в плане энергосбережения, поскольку устанавливает частоту процессора на минимально возможную, когда нагрузка на процессор невелика.
Однако, недавно я заметил, что у неё есть один недостаток: «ondemand» воспринимает нагрузку на процессор, вызванную операциями ввода-вывода, как «idle». Что это значит? Это значит, что при загрузке процессора операциями ввода-вывода частота процессора зачастую остаётся на пониженном уровне, что создаёт проблемы, если ваша система страдает от печально известного линуксового бага с iowait.
Бороться с таким поведением «ondemand» можно двумя способами.
Первый вариант — отключить энергосберегающий режим процессора. Например, исправив скрипт, который его включает. Он скрывается под вполне логичным именем «ondemand» и располагается в /etc/init.d . Если исправить в этом файле строку
, то процессор будет постоянно работать на максимальной частоте.
Второй вариант — включить для «ondemand» режим, в котором он не будет игнорировать iowait. Это управляется параметром в /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy . Для этого я написал маленький init-скрипт:
После этого скрипт сохраняется в файл /etc/init.d/io-is-busy , делается исполняемым и прописывается в системе командой sudo update-rc.d io-is-busy defaults 99 99 .
Всё. Теперь при повышении загрузки процессора операциями ввода-вывода, частота автоматически поднимается до максимальной, как мне и хотелось.
Ой, у вас баннер убежал!
Редакторский дайджест
Присылаем лучшие статьи раз в месяц
Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.
Похожие публикации
Некоторые аспекты управления VDS-сервером под Linux
Как устроена графика в Linux: обзор различных сред оформления рабочего стола
Настройка GUI WSL Kali Linux & Ubuntu. Выход в графическую оболочку
Вакансии
AdBlock похитил этот баннер, но баннеры не зубы — отрастут
Комментарии 63
Ну, в моём конкретном случае, это больше баг железа, чем софта, поскольку Windows 7 ведёт себя примерно так же, а баг воспроизводится на всех версиях ядра. Подозреваю, что причина в кривой реализации ADMA в чипсете nForce 500 SLI с одной стороны, и в не менее кривой реализации NCQ в некоторых винтах Western Digital (в результате чего на этих моделях NCQ в ядре заблокирован) — с другой. При копировании больших объёмов данных (особенно по сети) это приводит в солидной загрузке процессора, поэтому в данной ситуации повышение частоты процессора немного помогает.
Собственно, топик как раз и предназначен для тех, кто страдает от похожих проблем.
Когда надоест собирать час за часом софт из портов, возвращайтесь!
У самого стоит ArchLinux, Ubuntu, FreeBSD. Последняя только «для побаловаться», потому что система портов реально утомляет по сравнению с тем же pacman.
в итоге сранные баги только и делают, что лезут.
Вы, вероятно опечатались в слове «сраные». А лезут точно, да, как из рога изобилия.
Ой, да ладно. Сам недавно обновлял кеды — с -j5 и использованием mdfs для $WRKDIR (чтобы ускорить I/O). Всё довольно печально. Машинка, кстати, Phenom II X4 945. С тех пор кеды в портах уже опять обновились, но повторять сборку мне пока что неохота.
Хотя это был portupgrade, а не простой нативный make. Чем дальше, тем больше изъянов я у этого portupgrade нахожу.
А на бинарники полагаться особо не стоит. Не раз напарывался на ситуацию, когда хочешь поставить пакет, а тебе говорят «ой, пакета не существует, ставьте порт». Как-то так…
Там даже не в языке проблема, а в алгоритме обхода дерева при разрешении зависимостей пакетов. Кеды зависят от кутей, которые разбиты на много мелких пакетов. Каждый мелкий пакет указывает на один и тот же тарбол с исходниками (127 метров). portupgrade при обновлении проверяет, для всех ли пакетов скачаны тарболы и считает контрольную сумму. То есть, для каждого из этих qt-пакетов считает контрольную сумму большого тарбола qt — в моём случае несколько десятков раз. Затем находит пакет, для которого нет тарбола, качает его, и начинает проверять дерево зависимостей с самого начала. Снова проходит по всем этим пакетам, снова считает по нескольку десятков раз контрольную сумму большого тарбола qt… В общем, казалось, что это будет длиться вечно.
Плюнул, сел и обновился вручную по частям. Но осадок остался.
На третий день Зоркий Глаз заметил, что у сарая нет стены
core2duo e720, ubuntu 10.04 — не работает
>печально известного бага с iowait
Простите мне мою безграмотность, какого бага?
Баг довольно мерзкий, воспроизводится плохо — на определённых конфигурациях, при определённом положении звёзд.
А относительно профилей энергопотребления иногда включаю powersave на ночь. 700 мгц для качалки вполне хватает, а всякие флеш-баннеры пускай отдыхают. Результат — ровный и тихий шум вместо постоянно меняющейся скорости вентилятора, спать мешает намного меньше.
Главное утром не забыть сделать
cpufreq-selector -g ondemand
Можно засунуть в крон. Понятное дело, от рута или через sudo.
Длительное переключение между окнами вызвано малым объёмом оперативной памяти.
Окно не нарисуется, пока жёсткий диск не выдаст своп.
> есть один недостаток: «ondemand» воспринимает нагрузку на процессор, вызванную операциями ввода-вывода, как «idle». Что это значит?
Idle (от английского «бездействие») — это значит, что операции ввода-вывода не загружают процессор. Это называется IOwait (от английского «ждать») — процессор ждёт, пока жёсткий диск спозиционирует головки, проведёт операцию чтения или записи. Сам процессор при этом ничего не делает. Скорость позиционирования головок диска не зависит от тактовой частоты процессора. Следовательно, ускорить процесс ввода-вывода разгоном процессора нельзя. Любой современный процессор (даже в полуспящем режиме) обрабатывает данные более, чем на порядок быстрее любого жёсткого диска. Даже на 2 порядка. Ваш скрипт заставляет процессор ждать данных быстрее. Но быстрее они от этого прочитаны не будут. Прироста скорости нет. Проверье же, со скриптом и без. Только читайте разные файлы одинакового размера, а не один и тот же файл — дисковые операции кэшируются, что может исказить результат при чтении одного и того же файла. Для верности можно вообше перезагрузиться.
Также Вы совершенно напрасно думаете, что ядро не в состоянии самостоятельно переключать тактовую частоту в режиме ondemand. Если тактовая частота не поднимается самостоятельно ядром, то это одначает только одно — отсутствие нагрузки. Это Вы тоже можете проверить самостоятельно, почитав официальные руководства или заглянув в исходники ядра.
Мне скорее кажется, что это Вы не читали статью… Или не писали. Потому что работает этот скрипт так: процессор греется, электричество тратится, скорость работы НЕ увеличивается.
Ссылка на багрепорт есть?
> И из-ха неправильной работы DMA дисковая активность ложится на центральный процессор
Такая дисковая активность — порядка 20 мегабайт в секунду. Даже в энергосберегающем режиме эта активность не загрузит процессор и на 5%. Процессор практически отдыхает. Резона поднимать тактовую частоту у ядра нет.
Перечитайте ещё раз в моём предыдущем комментарии тезис про два порядка.
Знаете, я устал с вам спорить. Вам если не нужна эта фича — не используйте, ваше счастье.
А ваши сомнения по поводу полезности параметра io_is_busy можете отсылать автору следующего патча: kerneltrap.org/mailarchive/git-commits-head/2010/5/18/32999
Уверен, он вам гораздо лучше объяснит, зачем он его написал и как он работает.
Жаль, что устали. Проверить было бы быстрее, чем спорить.
Апплет «системный монитор» отлично показывает iowait, только другим цветом. И без всяких патчей, и без лишнего нагрева.
На реальное быстродействие на абсолютном большинстве систем патч не влияет. Фича не нужна.
Я прекрасно знаю, что показывает. И прекрасно знаю, что на моей системе — влияет. И лично мне эта фича нужна. Возможно, и ещё кому-нибудь пригодится.
Но вы, конечно, можете убедить автора патча в том, что он дурак, потому что его написал. А потом убедить Торвальдса, что тот дурак, потому что принял патч в ядро. Тогда они его уберут и мир станет светлым и прекрасным.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.