Pull to refresh

Comments 63

Ubuntu way: лечить симптомы а не багу
Вылечите багу, не стесняйтесь. Она ждала вас 3 года. За это время ни у кого не получилось, но я в вас верю.
try 2.6.34 luke
да, и кстати что думает ТС на тему взаимосвязи iowait и спящего режима проца в общем и целом а так же почему возросшая частота процессора затронула iowait в лучшую сторону
Ну, в моём конкретном случае, это больше баг железа, чем софта, поскольку Windows 7 ведёт себя примерно так же, а баг воспроизводится на всех версиях ядра. Подозреваю, что причина в кривой реализации ADMA в чипсете nForce 500 SLI с одной стороны, и в не менее кривой реализации NCQ в некоторых винтах Western Digital (в результате чего на этих моделях NCQ в ядре заблокирован) — с другой. При копировании больших объёмов данных (особенно по сети) это приводит в солидной загрузке процессора, поэтому в данной ситуации повышение частоты процессора немного помогает.

Собственно, топик как раз и предназначен для тех, кто страдает от похожих проблем.
Баг — это очень печально. Благодаря ему (наелся) сейчас серьёзно рассматриваю вариант ухода на FreeBSD на десктопе.
Когда надоест собирать час за часом софт из портов, возвращайтесь!

У самого стоит ArchLinux, Ubuntu, FreeBSD. Последняя только «для побаловаться», потому что система портов реально утомляет по сравнению с тем же pacman.
На 2ядерной машине это довольно быстро :) На 4ядерной ещё быстрее.
Более того, я начинал 5 лет назад именно с BSD, и даже на одноядерном атлоне XP в те времена всё работало довольно неплохо. Если, конечно, OpenOffice не собирать каждый день :) Но в BSD и бинарники есть, на крайний случай.
Там за основными портами конечно хорошо следят, но за теми, что нужны на десктопе, часто контроль плохой, в итоге сранные баги только и делают, что лезут.
в итоге сранные баги только и делают, что лезут.


Вы, вероятно опечатались в слове «сраные». А лезут точно, да, как из рога изобилия.
Ой, да ладно. Сам недавно обновлял кеды — с -j5 и использованием mdfs для $WRKDIR (чтобы ускорить I/O). Всё довольно печально. Машинка, кстати, Phenom II X4 945. С тех пор кеды в портах уже опять обновились, но повторять сборку мне пока что неохота.

Хотя это был portupgrade, а не простой нативный make. Чем дальше, тем больше изъянов я у этого portupgrade нахожу.

А на бинарники полагаться особо не стоит. Не раз напарывался на ситуацию, когда хочешь поставить пакет, а тебе говорят «ой, пакета не существует, ставьте порт». Как-то так…
portupgrade же это просто ruby обертка, нет? Впрочем ruby это очень тормозной язык, причем видимо, что называется by design. За простоту нужно платить
Там даже не в языке проблема, а в алгоритме обхода дерева при разрешении зависимостей пакетов. Кеды зависят от кутей, которые разбиты на много мелких пакетов. Каждый мелкий пакет указывает на один и тот же тарбол с исходниками (127 метров). portupgrade при обновлении проверяет, для всех ли пакетов скачаны тарболы и считает контрольную сумму. То есть, для каждого из этих qt-пакетов считает контрольную сумму большого тарбола qt — в моём случае несколько десятков раз!!! Затем находит пакет, для которого нет тарбола, качает его, и начинает проверять дерево зависимостей с самого начала. Снова проходит по всем этим пакетам, снова считает по нескольку десятков раз контрольную сумму большого тарбола qt… В общем, казалось, что это будет длиться вечно.

Плюнул, сел и обновился вручную по частям. Но осадок остался.
Мдя… ощущения как от студенческой поделки, ну не ужели про кеширование они не слышали?
Кстати, я тоже начинал именно с BSD и именно на одноядерном атлоне. Только 4 года назад, а не 5.
Эм. А смысл городить огород с отдельным скриптом вместо добавления одной строки в /etc/rc.local?
Смысл в том, что по умолчанию, судя по всему, в ядре указана политика «performance». Если она включена, то каталог /sys/devices/cpu/cpufreq пуст. Соответственно, параметры работы «ondemand» указать не получится. Поэтому мне хотелось привязать свой костыль к убунтушному (который включает ondemand). Убунтушники сделали так, чтобы система и рабочий стол грузились, пока стоит политика «performance», а потом автоматом включался «ondemand».
Замечательно. Только смысл было городить отдельный скрипт? Если внимательно посмотреть на содержимое /etc/rcX.d (вместо X подставить цифру), то можно заметить, что rc.local (S99rc.local) выполняется в том же порядке, что и ваш велосипед .
На третий день Зоркий Глаз заметил, что у сарая нет стены
Ага, только Зоркий Глаз ещё и заметил, что убунтушный костыль выполняется с задержкой 60 секунд. Так что скрипт городить всё равно надо, хотя бы однострочный. Хотя, кому хочется, может, конечно, и в rc.local прописать что-нибудь вроде «sleep 60 && echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy». Я сделал по своему, мне и так хорошо.
А можно уточнить, речь идет о сервере (голая консоль) или о десктопе с иксами?
Просто на десктопе вопрос решается активацией аплета Гнома и не требует ни каких скриптов.
А можно чуточку подробнее? Какой аплет?)
«Монитор изменения частоты процессора», сам им пользуюсь.
Единственный недостаток — приходится для каждого ядра устанавливать свой апплет.
core2duo e720, ubuntu 10.04 — не работает

Скорее всего, что-то нужно не установлено. Спросите на форуме, посвященном ubuntu, что нужно для работы.
Перечитайте статью, будьте добры. Речь идёт не о включении режима энергосбережения, а о настройке одного из его параметров.
Все равно не понял, гномовский апплет позволяет как минимизировать частоту, так и выставить среднюю и максимальную, и независимо имеет две настройки: «энергосбережение» и «производительность». Что я не правильно прочитал в статье?
Гномовский апплет не позволит настроить режим ondemand так, чтобы он воспринимал iowait не как idle, а как загруженность процессора.
>печально известного бага с iowait

Простите мне мою безграмотность, какого бага?
У меня этот параметр по умолчанию включен. убунту 10.10 на работе и генту дома
UFO just landed and posted this here
Возможно и так. Вот только у меня на некоторых версиях ядра банальное переключение между соседними окнами занимало от 20 секунд до минуты, когда система загружена iowait. Странный iowait.
UFO just landed and posted this here
А как IO подсистема связана, пардон, с переключением между окнами?
UFO just landed and posted this here
Ну какое может быть обращение к файлам при переключении между двумя окнами виртуального терминала? А своп отключен, такие дела.
UFO just landed and posted this here
Да, причём заметно. Теперь я даже могу рулить плеером, при запущенной виртуальной машине, копировании по сети в фоне и работающем свопе.
UFO just landed and posted this here
UFO just landed and posted this here
На днях посыпалась одна планка памяти, вынул ее. Теперь я тоже не по наслышке знаю, что такое баг «12309»! Ловлю перманентные тормоза с IOWait. =\
Что то я не понял, код /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy
этого скрипта где можно найти?
Это не код, это файл по адресу /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy. Директория /sys/devices/system/cpu/cpufreq/ondemand/ появляется, если включён режим управления частотой процессора «ondemand».
А как можно лично увидеть эту проблему с iowait? Впервые про неё слышу, нужно ведь убедиться что нужно что-то предпринимать :)
Офигеть. Чего только на лурке нет. о_О
Я согласен с pentarh.
На длительность процессов ввода-вывода влияет, преимущественно, скорость жёсткого диска.
Длительное переключение между окнами вызвано малым объёмом оперативной памяти.
Окно не нарисуется, пока жёсткий диск не выдаст своп.
Увеличение частоты процессора на скорость считывания информации с диска в память ровно никак не повлияет.
Единственный результат работы скрипта — тёплый воздух в комнате и лишняя денюшка чубайсам.
Я такую проблему решил раз и на всегда, докупив гиг памяти и совсем отключив своп в fstab.
А относительно профилей энергопотребления иногда включаю powersave на ночь. 700 мгц для качалки вполне хватает, а всякие флеш-баннеры пускай отдыхают. Результат — ровный и тихий шум вместо постоянно меняющейся скорости вентилятора, спать мешает намного меньше.

Главное утром не забыть сделать
cpufreq-selector -g ondemand

Можно засунуть в крон. Понятное дело, от рута или через sudo.
Я ночью вообще компьютер выключаю, у меня сервачок на балконе стоит для этих дел.
Длительное переключение между окнами вызвано малым объёмом оперативной памяти.
Окно не нарисуется, пока жёсткий диск не выдаст своп.

Я уже писал, что своп был отключен и так.
Тогда система при переключении окон сама «разгонит» процессор, если дело в нём. Непонятно, зачем его держать горячим всё время.
Вы вообще статью читали или так, только заголовок?
> есть один недостаток: «ondemand» воспринимает нагрузку на процессор, вызванную операциями ввода-вывода, как «idle». Что это значит?

Idle (от английского «бездействие») — это значит, что операции ввода-вывода не загружают процессор. Это называется IOwait (от английского «ждать») — процессор ждёт, пока жёсткий диск спозиционирует головки, проведёт операцию чтения или записи. Сам процессор при этом ничего не делает. Скорость позиционирования головок диска не зависит от тактовой частоты процессора. Следовательно, ускорить процесс ввода-вывода разгоном процессора нельзя. Любой современный процессор (даже в полуспящем режиме) обрабатывает данные более, чем на порядок быстрее любого жёсткого диска. Даже на 2 порядка. Ваш скрипт заставляет процессор ждать данных быстрее. Но быстрее они от этого прочитаны не будут. Прироста скорости нет. Проверье же, со скриптом и без. Только читайте разные файлы одинакового размера, а не один и тот же файл — дисковые операции кэшируются, что может исказить результат при чтении одного и того же файла. Для верности можно вообше перезагрузиться.

Также Вы совершенно напрасно думаете, что ядро не в состоянии самостоятельно переключать тактовую частоту в режиме ondemand. Если тактовая частота не поднимается самостоятельно ядром, то это одначает только одно — отсутствие нагрузки. Это Вы тоже можете проверить самостоятельно, почитав официальные руководства или заглянув в исходники ядра.

Мне скорее кажется, что это Вы не читали статью… Или не писали. Потому что работает этот скрипт так: процессор греется, электричество тратится, скорость работы НЕ увеличивается.
А теперь представьте себе, что в результате бага в драйвере (или в самом чипсете) у вас неправильно работает DMA (включение ADMA в драйвере для сата-контроллера приводит к потере данных, не нашёл данных о том, что такое это ADMA — то ли альтернативное название для DMA, то ли его расширение). И из-ха неправильной работы DMA дисковая активность ложится на центральный процессор. При этом ядро регистрирует эту активность как iowait и воспринимает как idle.
Ссылка на багрепорт есть?

> И из-ха неправильной работы DMA дисковая активность ложится на центральный процессор

Такая дисковая активность — порядка 20 мегабайт в секунду. Даже в энергосберегающем режиме эта активность не загрузит процессор и на 5%. Процессор практически отдыхает. Резона поднимать тактовую частоту у ядра нет.

Перечитайте ещё раз в моём предыдущем комментарии тезис про два порядка.
Знаете, я устал с вам спорить. Вам если не нужна эта фича — не используйте, ваше счастье.

А ваши сомнения по поводу полезности параметра io_is_busy можете отсылать автору следующего патча: kerneltrap.org/mailarchive/git-commits-head/2010/5/18/32999

Уверен, он вам гораздо лучше объяснит, зачем он его написал и как он работает.
Жаль, что устали. Проверить было бы быстрее, чем спорить.

Апплет «системный монитор» отлично показывает iowait, только другим цветом. И без всяких патчей, и без лишнего нагрева.

На реальное быстродействие на абсолютном большинстве систем патч не влияет. Фича не нужна.
Я прекрасно знаю, что показывает. И прекрасно знаю, что на моей системе — влияет. И лично мне эта фича нужна. Возможно, и ещё кому-нибудь пригодится.

Но вы, конечно, можете убедить автора патча в том, что он дурак, потому что его написал. А потом убедить Торвальдса, что тот дурак, потому что принял патч в ядро. Тогда они его уберут и мир станет светлым и прекрасным.
Only those users with full accounts are able to leave comments. Log in, please.

Articles