2.6.15 - iowait 90%

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

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

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

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

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

iostat, top, vmstat

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

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

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

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

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

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

iostat, top, vmstat

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

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

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

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

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

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

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

А ты не тупи и подумай почему у тебя фризы, если процессор не загружен. Потом проследуй в ВиКи и сделай как там сказано: www.linux.org.ru/wiki/en/User:shimon/12309

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

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