Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 63
Ubuntu way: лечить симптомы а не багу
Вылечите багу, не стесняйтесь. Она ждала вас 3 года. За это время ни у кого не получилось, но я в вас верю.
try 2.6.34 luke
да, и кстати что думает ТС на тему взаимосвязи iowait и спящего режима проца в общем и целом а так же почему возросшая частота процессора затронула iowait в лучшую сторону
да, и кстати что думает ТС на тему взаимосвязи iowait и спящего режима проца в общем и целом а так же почему возросшая частота процессора затронула iowait в лучшую сторону
Ну, в моём конкретном случае, это больше баг железа, чем софта, поскольку Windows 7 ведёт себя примерно так же, а баг воспроизводится на всех версиях ядра. Подозреваю, что причина в кривой реализации ADMA в чипсете nForce 500 SLI с одной стороны, и в не менее кривой реализации NCQ в некоторых винтах Western Digital (в результате чего на этих моделях NCQ в ядре заблокирован) — с другой. При копировании больших объёмов данных (особенно по сети) это приводит в солидной загрузке процессора, поэтому в данной ситуации повышение частоты процессора немного помогает.
Собственно, топик как раз и предназначен для тех, кто страдает от похожих проблем.
Собственно, топик как раз и предназначен для тех, кто страдает от похожих проблем.
Баг — это очень печально. Благодаря ему (наелся) сейчас серьёзно рассматриваю вариант ухода на FreeBSD на десктопе.
Когда надоест собирать час за часом софт из портов, возвращайтесь!
У самого стоит ArchLinux, Ubuntu, FreeBSD. Последняя только «для побаловаться», потому что система портов реально утомляет по сравнению с тем же pacman.
У самого стоит ArchLinux, Ubuntu, FreeBSD. Последняя только «для побаловаться», потому что система портов реально утомляет по сравнению с тем же pacman.
На 2ядерной машине это довольно быстро :) На 4ядерной ещё быстрее.
Более того, я начинал 5 лет назад именно с BSD, и даже на одноядерном атлоне XP в те времена всё работало довольно неплохо. Если, конечно, OpenOffice не собирать каждый день :) Но в BSD и бинарники есть, на крайний случай.
Более того, я начинал 5 лет назад именно с BSD, и даже на одноядерном атлоне XP в те времена всё работало довольно неплохо. Если, конечно, OpenOffice не собирать каждый день :) Но в BSD и бинарники есть, на крайний случай.
Там за основными портами конечно хорошо следят, но за теми, что нужны на десктопе, часто контроль плохой, в итоге сранные баги только и делают, что лезут.
Ой, да ладно. Сам недавно обновлял кеды — с -j5 и использованием mdfs для $WRKDIR (чтобы ускорить I/O). Всё довольно печально. Машинка, кстати, Phenom II X4 945. С тех пор кеды в портах уже опять обновились, но повторять сборку мне пока что неохота.
Хотя это был portupgrade, а не простой нативный make. Чем дальше, тем больше изъянов я у этого portupgrade нахожу.
А на бинарники полагаться особо не стоит. Не раз напарывался на ситуацию, когда хочешь поставить пакет, а тебе говорят «ой, пакета не существует, ставьте порт». Как-то так…
Хотя это был 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». Я сделал по своему, мне и так хорошо.
А можно уточнить, речь идет о сервере (голая консоль) или о десктопе с иксами?
Просто на десктопе вопрос решается активацией аплета Гнома и не требует ни каких скриптов.
Просто на десктопе вопрос решается активацией аплета Гнома и не требует ни каких скриптов.
А можно чуточку подробнее? Какой аплет?)
Перечитайте статью, будьте добры. Речь идёт не о включении режима энергосбережения, а о настройке одного из его параметров.
>печально известного бага с iowait
Простите мне мою безграмотность, какого бага?
Простите мне мою безграмотность, какого бага?
google://12309
У меня этот параметр по умолчанию включен. убунту 10.10 на работе и генту дома
Возможно и так. Вот только у меня на некоторых версиях ядра банальное переключение между соседними окнами занимало от 20 секунд до минуты, когда система загружена iowait. Странный iowait.
поведайте зачем скрипт, плз.
> печально известного линуксового бага с iowait.
я с линукс в качестве десктопа использую больше 6 лет, а с серверами работаю и того дольше и мне ничего не известно о баге с iowait. что за баг?
я с линукс в качестве десктопа использую больше 6 лет, а с серверами работаю и того дольше и мне ничего не известно о баге с iowait. что за баг?
Чуть выше отписали: habrahabr.ru/blogs/linux/110547/#comment_3518769
Баг довольно мерзкий, воспроизводится плохо — на определённых конфигурациях, при определённом положении звёзд.
Баг довольно мерзкий, воспроизводится плохо — на определённых конфигурациях, при определённом положении звёзд.
у вас нет и слава богу — а мы огребли
www.google.ru/search?q=100%25&submit=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA&sitesearch=ubuntu.ru&hl=ru
www.google.ru/search?q=100%25&submit=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA&sitesearch=ubuntu.ru&hl=ru
На днях посыпалась одна планка памяти, вынул ее. Теперь я тоже не по наслышке знаю, что такое баг «12309»! Ловлю перманентные тормоза с IOWait. =\
Что то я не понял, код /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy
этого скрипта где можно найти?
этого скрипта где можно найти?
А как можно лично увидеть эту проблему с iowait? Впервые про неё слышу, нужно ведь убедиться что нужно что-то предпринимать :)
lurkmore.ru/12309
там есть инструкция
там есть инструкция
Я согласен с pentarh.
На длительность процессов ввода-вывода влияет, преимущественно, скорость жёсткого диска.
Длительное переключение между окнами вызвано малым объёмом оперативной памяти.
Окно не нарисуется, пока жёсткий диск не выдаст своп.
Увеличение частоты процессора на скорость считывания информации с диска в память ровно никак не повлияет.
Единственный результат работы скрипта — тёплый воздух в комнате и лишняя денюшка чубайсам.
Я такую проблему решил раз и на всегда, докупив гиг памяти и совсем отключив своп в fstab.
На длительность процессов ввода-вывода влияет, преимущественно, скорость жёсткого диска.
Длительное переключение между окнами вызвано малым объёмом оперативной памяти.
Окно не нарисуется, пока жёсткий диск не выдаст своп.
Увеличение частоты процессора на скорость считывания информации с диска в память ровно никак не повлияет.
Единственный результат работы скрипта — тёплый воздух в комнате и лишняя денюшка чубайсам.
Я такую проблему решил раз и на всегда, докупив гиг памяти и совсем отключив своп в fstab.
А относительно профилей энергопотребления иногда включаю powersave на ночь. 700 мгц для качалки вполне хватает, а всякие флеш-баннеры пускай отдыхают. Результат — ровный и тихий шум вместо постоянно меняющейся скорости вентилятора, спать мешает намного меньше.
Главное утром не забыть сделать
cpufreq-selector -g ondemand
Можно засунуть в крон. Понятное дело, от рута или через sudo.
Главное утром не забыть сделать
cpufreq-selector -g ondemand
Можно засунуть в крон. Понятное дело, от рута или через sudo.
Длительное переключение между окнами вызвано малым объёмом оперативной памяти.
Окно не нарисуется, пока жёсткий диск не выдаст своп.
Я уже писал, что своп был отключен и так.
Тогда система при переключении окон сама «разгонит» процессор, если дело в нём. Непонятно, зачем его держать горячим всё время.
Вы вообще статью читали или так, только заголовок?
> есть один недостаток: «ondemand» воспринимает нагрузку на процессор, вызванную операциями ввода-вывода, как «idle». Что это значит?
Idle (от английского «бездействие») — это значит, что операции ввода-вывода не загружают процессор. Это называется IOwait (от английского «ждать») — процессор ждёт, пока жёсткий диск спозиционирует головки, проведёт операцию чтения или записи. Сам процессор при этом ничего не делает. Скорость позиционирования головок диска не зависит от тактовой частоты процессора. Следовательно, ускорить процесс ввода-вывода разгоном процессора нельзя. Любой современный процессор (даже в полуспящем режиме) обрабатывает данные более, чем на порядок быстрее любого жёсткого диска. Даже на 2 порядка. Ваш скрипт заставляет процессор ждать данных быстрее. Но быстрее они от этого прочитаны не будут. Прироста скорости нет. Проверье же, со скриптом и без. Только читайте разные файлы одинакового размера, а не один и тот же файл — дисковые операции кэшируются, что может исказить результат при чтении одного и того же файла. Для верности можно вообше перезагрузиться.
Также Вы совершенно напрасно думаете, что ядро не в состоянии самостоятельно переключать тактовую частоту в режиме ondemand. Если тактовая частота не поднимается самостоятельно ядром, то это одначает только одно — отсутствие нагрузки. Это Вы тоже можете проверить самостоятельно, почитав официальные руководства или заглянув в исходники ядра.
Мне скорее кажется, что это Вы не читали статью… Или не писали. Потому что работает этот скрипт так: процессор греется, электричество тратится, скорость работы НЕ увеличивается.
Idle (от английского «бездействие») — это значит, что операции ввода-вывода не загружают процессор. Это называется IOwait (от английского «ждать») — процессор ждёт, пока жёсткий диск спозиционирует головки, проведёт операцию чтения или записи. Сам процессор при этом ничего не делает. Скорость позиционирования головок диска не зависит от тактовой частоты процессора. Следовательно, ускорить процесс ввода-вывода разгоном процессора нельзя. Любой современный процессор (даже в полуспящем режиме) обрабатывает данные более, чем на порядок быстрее любого жёсткого диска. Даже на 2 порядка. Ваш скрипт заставляет процессор ждать данных быстрее. Но быстрее они от этого прочитаны не будут. Прироста скорости нет. Проверье же, со скриптом и без. Только читайте разные файлы одинакового размера, а не один и тот же файл — дисковые операции кэшируются, что может исказить результат при чтении одного и того же файла. Для верности можно вообше перезагрузиться.
Также Вы совершенно напрасно думаете, что ядро не в состоянии самостоятельно переключать тактовую частоту в режиме ondemand. Если тактовая частота не поднимается самостоятельно ядром, то это одначает только одно — отсутствие нагрузки. Это Вы тоже можете проверить самостоятельно, почитав официальные руководства или заглянув в исходники ядра.
Мне скорее кажется, что это Вы не читали статью… Или не писали. Потому что работает этот скрипт так: процессор греется, электричество тратится, скорость работы НЕ увеличивается.
А теперь представьте себе, что в результате бага в драйвере (или в самом чипсете) у вас неправильно работает DMA (включение ADMA в драйвере для сата-контроллера приводит к потере данных, не нашёл данных о том, что такое это ADMA — то ли альтернативное название для DMA, то ли его расширение). И из-ха неправильной работы DMA дисковая активность ложится на центральный процессор. При этом ядро регистрирует эту активность как iowait и воспринимает как idle.
Ссылка на багрепорт есть?
> И из-ха неправильной работы DMA дисковая активность ложится на центральный процессор
Такая дисковая активность — порядка 20 мегабайт в секунду. Даже в энергосберегающем режиме эта активность не загрузит процессор и на 5%. Процессор практически отдыхает. Резона поднимать тактовую частоту у ядра нет.
Перечитайте ещё раз в моём предыдущем комментарии тезис про два порядка.
> И из-ха неправильной работы DMA дисковая активность ложится на центральный процессор
Такая дисковая активность — порядка 20 мегабайт в секунду. Даже в энергосберегающем режиме эта активность не загрузит процессор и на 5%. Процессор практически отдыхает. Резона поднимать тактовую частоту у ядра нет.
Перечитайте ещё раз в моём предыдущем комментарии тезис про два порядка.
Знаете, я устал с вам спорить. Вам если не нужна эта фича — не используйте, ваше счастье.
А ваши сомнения по поводу полезности параметра io_is_busy можете отсылать автору следующего патча: kerneltrap.org/mailarchive/git-commits-head/2010/5/18/32999
Уверен, он вам гораздо лучше объяснит, зачем он его написал и как он работает.
А ваши сомнения по поводу полезности параметра io_is_busy можете отсылать автору следующего патча: kerneltrap.org/mailarchive/git-commits-head/2010/5/18/32999
Уверен, он вам гораздо лучше объяснит, зачем он его написал и как он работает.
Жаль, что устали. Проверить было бы быстрее, чем спорить.
Апплет «системный монитор» отлично показывает iowait, только другим цветом. И без всяких патчей, и без лишнего нагрева.
На реальное быстродействие на абсолютном большинстве систем патч не влияет. Фича не нужна.
Апплет «системный монитор» отлично показывает iowait, только другим цветом. И без всяких патчей, и без лишнего нагрева.
На реальное быстродействие на абсолютном большинстве систем патч не влияет. Фича не нужна.
Я прекрасно знаю, что показывает. И прекрасно знаю, что на моей системе — влияет. И лично мне эта фича нужна. Возможно, и ещё кому-нибудь пригодится.
Но вы, конечно, можете убедить автора патча в том, что он дурак, потому что его написал. А потом убедить Торвальдса, что тот дурак, потому что принял патч в ядро. Тогда они его уберут и мир станет светлым и прекрасным.
Но вы, конечно, можете убедить автора патча в том, что он дурак, потому что его написал. А потом убедить Торвальдса, что тот дурак, потому что принял патч в ядро. Тогда они его уберут и мир станет светлым и прекрасным.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Политика управления частотой процессора «ondemand» и iowait в Ubuntu