LINUX.ORG.RU

2.6.15 - iowait 90%

 


0

1

И опять он :) Недавно скачал бубунту древнюю с версией ядра 2.6.15. У меня был раздел на 17 гигов, который я на данный момент не использовал. Я его отформатировал в ext3, скопировал туда сорцы ядра и забутился с ливсд на бубунту. Зашёл в бубунту, подмонтировал раздел, вроде все норм. Начал копировать сырцы на тотже раздел тока под другим именем. iowait - 80-95%, загрузка процессора(общая!) в пределах 15%. Это учитывая то, что я копировал через наутилус, то-есть гуйня тоже отжирала слегка процессора. Попробовал поюзать систему, вроде нормально. Потом, добавил хардкора, начал ещё копирование на флешку - мышка не виснет. Начал юзать все что под руку попадётся - запускать все что было в ливсд. Вроде нормально. Начал закрывать все - мышка пару раз зафризилась(возможно кеш сбросился, и надо было поигратся с sync?). И вот какую фичу я узрел, точнее не фичу, а разницу между теперешним ведром(3.3.0) и 2.6.15. Иоваит был почти 100% при юзании IO операций, НО, если я начинал чтото делать, к примеру использовать проги которым нужно много процессора, iowait падал, и падал до нуля. Тоесть, видимо здесь какие-то приоритеты играют роль, яхз. И вторая фишка, которую я заметил, это разный подсчет загрузки процессора. В новых ядрах этот подсчет ведётся с учётом iowait, то-есть загрузка проца __никогда__ не бывает меньше иовейта. В 2.6.15 загрузка проца была меньше иоваита, и намного. Значит, либо в подсчёте загрузки какая-то ошибка, либо в старом ядре была ошибка, а теперешний вариант подсчёта - правильный. Прошу мнения гуру, нужно ли растолковать свои наблюдения на багзиле. Создавать новый баг(так как я не знаю относится ли то, что я описал к 12309), либо дописать в коментарии к 12309.

ведро 2.6.15 как и древние убунты unsupported.

bhfq ★★★★★ ()
Ответ на: комментарий от bhfq

причем тут суппортед/унсупортед? Я привожу изменение поведения работы, за счёт которых возможно и была регрессия.

vova7890 ★★★ ()
Ответ на: комментарий от vova7890

Вова, а ты не хочешь поведать миру о том, какая программа показывает тебе этот самый iowait? Возможно ты и выхлоп этой программы мог бы тут привести вместо того, чтобы многословно ругаться на кернел.

anonymous ()

Ну что за простыня?! Прошу, отформатируй!

leonidko ★★★ ()

Молодец, продолжай наблюдать и дальше. Есть ещё ядра веток 2.4, 2.2 и 2.0. Попробуй ещё с ними.
Только вот при разнице в 23 релиза твои наблюдения не актуальны.

imul ★★★★★ ()
Ответ на: комментарий от imul

Разнице? Я сравнил ядра в которых есть иовейт баг, и в котором, по словам гугла, его не удалось воиспроизвести. 2.6.18 - последнее, я взял меньше.

vova7890 ★★★ ()
Ответ на: комментарий от vova7890

Это всё конечно замечательно, но методологически просто ужасно. Потом этот iowait баг никому не мешал. Ну считалось время ожидания ввода-вывода за нагрузку на процессор, реально же никакой нагрузки не было.

imul ★★★★★ ()
Ответ на: комментарий от imul

ну то, что в расчетах загрузки процессора ошибка(возможно) то пол беды. Беда в том, что и в ранних версиях ядра проявляется завышенный иоваит(но на загрузку процессора это не влияло). Хотя, как некоторые утверждают, у кого иоваит баг не проявляется, что он никогда больше 20% не бывает....

vova7890 ★★★ ()
Ответ на: комментарий от vova7890

Это сильно зависело от контроллера ввода-вывода. У кого-то было 100% при копировании из-за iowait, у кого-то нет. Также как и сейчас, у кого-то есть 12309, а кто-то не знает, что это такое и как выглядит, но в этом случае факторов влияния намного больше.
Методически правильно на одном железе сравнивать с одним и тем же .config ядра подряд. Чтобы можно было точнее сказать, что, где на что повлияло и каким образом. А то можно насравнивать... hda с sda.

imul ★★★★★ ()
Ответ на: комментарий от imul

От оборудования зависело, да. Скажу даже больше, у меня тот «баговый» nforce чип. А баг чипа был в том, что он слал прерывания с огромнной скоростью при ио операциях, а так как прерывания обрабатываются на уровне планировщика процессов и их приоритет выше всех, то это сказывалось на скорости работы системы. Но вот что я вам скажу, странно да, но bsd и шиндовс с ним работает нормально, никаких иоваит багов. Это первое, второе что я вам скажу, в новых версиях(3.3 например) ядра, я наблюдал за прерываниями ahci, их было прилично мало, и при ио операциях они вываливались умеренно, и не с огромной скоростью(это с cfs планировщиком процессов, с bfs - прерывания летели шо угорелые, система на нём висла ещё больше). Так вот, в баговость чипов мне что-то мало верится.

Эх... Самое страшное в баге - его рендомность :)

vova7890 ★★★ ()
Ответ на: комментарий от vova7890

iostat, top, vmstat

Ну а где выхлоп vmstat где «загрузка проца __никогда__ не бывает меньше иовейта» при wa >50% ?

anonymous ()
Ответ на: комментарий от imul

Потом этот iowait баг никому не мешал. Ну считалось время ожидания ввода-вывода за нагрузку на процессор, реально же никакой нагрузки не было.

Гы. Это потому появление CFQ было как глоток свежего воздуха? Надо же, на интенсивной дисковой работе мышка перестала затыкаться! :D

KRoN73 ★★★★★ ()
Ответ на: комментарий от vova7890

От оборудования зависело, да. Скажу даже больше, у меня тот «баговый» nforce чип.

На nForce — вообще жесть была. Там и CFQ не спасал :) Так и мучился, пока мать не сменил.

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

Это просто образец того, что сломанное в одном месте починили улучшением в другом.

imul ★★★★★ ()
Ответ на: комментарий от KRoN73

Вот у меня сейчас такая жесть. Тупо фризы начиная от минуты заканчивая 30 минутами(рекорд). Как же оно меня задолбало уже ...

vova7890 ★★★ ()
Ответ на: комментарий от anonymous

процессор как раз таки загружен, хрен знает чем. иовейтом видимо оО. Всяких костылей я уже тысячи перепробовал. Все эти костыля для тех у кого «подвисания» а не получасовые фризы.

vova7890 ★★★ ()
Ответ на: комментарий от vova7890

wa - это процессор не загружен. Если не в состоянии понять почему так происходит, то просто сделай так как сказано в ВиКи. Уверен что тебе поможет.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.