Моя борьба: бага в ядрах 2.6

С недавних пор мной была обнаружена некоторая
странность при работе ядер из новой ветки 2.6. При интенсивном обращении к дисковому накопителю наблюдалась некоторая тормознутость. Сначала все списывалось на собственную реактивность, кривые руки, фазы луны и прочие вещи. Но потом это таки достало и я начал искать
где же тут грабли зарыты.

В качестве лирического отступления: в качестве графической оболочки я использую icewm. Классная красива штука, которую можно хорошо настроить. Не жрет ресурсов. Думаю всем хорошо известен маленький графический индикатор уровня загрузки процессора в правом нижнем углу.

Долго я промучался с тормознутостью FedoraCore2. Плюнул на все, обозвал криворуким себя и дистромэйкеров. Откатился на ASP9.2 Как вам известно, сей дистр сделан на основе FedoraCore1 и ядра 2.4.22. Сидел я там и радовался как все летает. Но в один прекрасный день мне захотелось
поэкспериментировать с 2.6.7. В общем скачал я его, скомпилил и поставил. И в тот-же день меня поразила одна неприятная фигня. При ядре 2.4.22 вышеупомянутый индикатор загруженности процессора при копировании больших
объемов информации показывал зеленым цветом небольшую активность в пределах 7-10%. При копировании же на ядре 2.6. это окошечко почти напрочь забивалось красным цветом!!! Оба-на, подумал я. DMA не завелось. Потом смотрю на скорость копирования и понимаю, что ни при каком PIO такой скорости быть не может. Гашу нафиг копирование. Делаю hdparm -t
/dev/hda. И вижу 52 мегабайта в секунду. Какое нафиг тут ПИО!!! Все летает. Даже чуть быстрее чем на 2.4. Делаю hdparm -i /dev/hda и вижу 

UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 

Все работает!! В одной консоли запускаю top, в другой копирование фильма в другую папку. Индикатор загруженности сразу покрывается красным. Гляжу в
top:

07:34:20 up 11:22, 5 users, load average: 0,68, 0,18, 0,13 
87 processes: 85 sleeping, 2 running, 0 zombie, 0 stopped 
CPU states: cpu user nice system irq softirq iowait idle 
total 3,7% 0,0% 14,5% 0,9% 0,0% 80,8% 0,0% 
Mem: 255872k av, 253736k used, 2136k free, 0k shrd, 632k buff 
106452k active, 117268k inactive 
Swap: 530104k av, 0k used, 530104k free 156200k cached 
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 
13779 serg 18 0 6224 1840 5812 D 13,2 0,7 0:01 0 mc 
44 root 15 0 0 0 0 SW 1,0 0,0 0:02 0 kswapd0 
13403 serg 15 0 162M 14M 160M S 0,9 5,8 0:02 0 konsole 
1529 root 15 0 163M 21M 144M S 0,7 8,7 10:01 0 X 
43 root 15 0 0 0 0 SW 0,4 0,0 0:01 0 pdflush 
2009 serg 15 0 24816 8180 12904 S 0,4 3,1 0:24 0 xmms 

80% ресурса проца идет на ожидание ввода-вывода. Что за байда? Делаю reboot. Выбираю родное 2.4.22. Запускаю все то
же самое. Iowait по нулям. Общая загрузка не больше 10%. С тех пор много и-нета я перегуглил, спалил дохрена траффика. Подоставал людей на форумах. Облазил сайт Нвидия по поводу всего, что связано с чипсетами. Перепробовал кучу ядер ветки 2.6. и кучу патчей. Все оставалось как прежде. В последнее время частенько я начал встречать в нете мнение, что в ядрах 2.4. в idle писалось суммарное значение свободных ресурсов плюс ожидание ввода-вывода.
То есть просто в ядрах 2.6. индикация ресурсов проводится немного по другому и на производительность это влиять не должно. ХРЕН ВАМ!!! - сказал я и придумал эти тесты.

Тестирование 

Конфигурация системы: 
- AthlonXP Barton 2500+@3200+ 
- MB Asus A7N8X Nforce2 
- 256 Mb DDR400 NCP 
- Seagate Barracuda 120Gb 7200RPM 2Mb cache 
[serg@cherep temp]# hdparm -i /dev/hda 
/dev/hda: 
Model=ST3120022A, FwRev=3.06, SerialNo=5JT03EF9 
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% } 
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4 
BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=16 
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=234441648 
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120} 
PIO modes: pio0 pio1 pio2 pio3 pio4 
DMA modes: mdma0 mdma1 mdma2 
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 
AdvancedPM=no WriteCache=enabled 
Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2: 
* signifies the current active mode 

Тесты: 

1. Информация про скорость считывания с носителя hdparm -t
/dev/hda. Делается три раза и берется средний результат.

2. Измерение времени копирования файла 1.avi размером 719754K в файл 2.avi,
организовано скриптом copy:
[serg@cherep temp]# cat copy 
time cp 1.avi 2.avi 
rm 2.avi 
Измерения делаются 3 раза и берется средний результат.

3. Измерения времени распаковки архива ядра 2.6.8.1,
организовано скриптом unpack:
[serg@cherep temp]# cat unpack 
time bzip2 -cd linux-2.6.8.1.tar.bz2 | tar xvf - 
rm -rf linux-2.6.8.1 
Измерения делаются 3 раза и берется средний результат.

4. Самый главный тест. Его целью является выявить как сказывается на
производительности системы под разными ядрами работа с диском. Для этого
загружаем комп копированием с помощью скрипта copy1:
[serg@cherep temp]# cat copy1 
cp 1.avi 2.avi 
rm 2.avi 
./copy1 
И в это время запускаем на компиляцию ядро 2.6.8.1 и измеряем время его компиляции: 
time make bzImage 
Для интереса замеряем чистое время компиляции ядра без дополнительных нагрузок: 
time make bzImage 
(без запущенного copy1) 

Конфиг в каждом случае один и тот-же. Каталог каждый раз перед сборкой чистится mrproper.
Этот тест нехило напрягает веник 🙂 Поэтому если вы не уверены в его надежности и достаточном
охлаждении - прошу не повторять.

Тестировались ядра: 

2.4.22 - родное ядро из коробки ASP 9.2 
2.4.22 - собранное с оптимизацией под конкретную систему 
2.4.27 - последнее стабильное ядро в ветке 2.4. 
2.6.8.1 - последнее стабильное ядро в ветке 2.6. 

Примечания: 

Все это производилось в голой консоли без иксов. Все ненужные демоны типа roftpd были выключены (дабы никакая падла не испортила эксперимента скачкой фильмов), сетевые интерфейсы погашены. /В соседней консоли
через mpg312 играл Мастер/

Результаты тестов 

kelnel 2.4.22 asp9.2 native 

Тест #1: 
[serg@cherep serg]# hdparm -t /dev/hda 
/dev/hda: 
Timing buffered disk reads: 154 MB in 3.02 seconds = 50.99 MB/sec 

Тест #2: 
[serg@cherep temp]# ./copy 
real 0m31.627s 
user 0m0.020s 
sys 0m3.530s 

Тест #3: 
[serg@cherep temp]#./unpack 
real 0m35.206s 
user 0m19.140s 
sys 0m2.060s 

Тест #4: 
Запускаем с другой консоли copy1 для нагрузки диска. 
Заходим в /usr/src/linux-2.6.8.test 
make mrproper 
cp /mnt/all/.config /usr/src/linux-2.6.8.test/.config 
make oldconfig 
time make bzImage 
Получаем: 
Kernel: arch/i386/boot/bzImage is ready 
298.950u 32.860s 10:23.81 56.0% 0+0k 0+0io 2364358pf+0w 
Гасим copy1 
Заходим в /usr/src/linux-2.6.8.test 
make mrproper 
cp /mnt/all/.config /usr/src/linux-2.6.8.test/.config 
make oldconfig 
time make bzImage 

Получаем: 
Kernel: arch/i386/boot/bzImage is ready 
289.950u 22.860s 5:35.81 96.0% 0+0k 0+0io 2364358pf+0w 

Итак, под нагрузкой постоянного копирования
большого файла ядро обирается в два раза медленнее - 10m23s против 5m35s 

kernel 2.4.22my 

Тест #1: 
[serg@cherep temp]# hdparm -t /dev/hda 
/dev/hda: 
Timing buffered disk reads: 152 MB in 3.00 seconds = 50.67 MB/sec 

Тест #2: 
[serg@cherep temp]# ./copy 
real 0m33.848s 
user 0m0.020s 
sys 0m3.320s 

Тест #3: 
[serg@cherep temp]#./unpack 
real 0m35.121s 
user 0m19.120s 
sys 0m1.830s 

Тест #4: 
Запускаем с другой консоли copy1 для нагрузки диска. 
Заходим в /usr/src/linux-2.6.8.test 
make mrproper 
cp /mnt/all/.config /usr/src/linux-2.6.8.test/.config 
make oldconfig 
time make bzImage 
Получаем: 
Kernel: arch/i386/boot/bzImage is ready 
298.860u 32.490s 10:22.20 54.1% 0+0k 0+0io 2364374pf+0w 
Гасим copy1 
Заходим в /usr/src/linux-2.6.8.test 
make mrproper 
cp /mnt/all/.config /usr/src/linux-2.6.8.test/.config 
make oldconfig 
time make bzImage 
Получаем: 
Kernel: arch/i386/boot/bzImage is ready 
289.930u 23.230s 5:30.94 94.6% 0+0k 0+0io 2364358pf+0w 

Практически аналогичная картина. Разница почти в два раза. 

kernel 2.4.27 

Тест #1: 
[serg@cherep temp]# hdparm -t /dev/hda 
/dev/hda: 
Timing buffered disk reads: 152 MB in 3.02 seconds = 50.33 MB/sec 

Тест #2: 
[serg@cherep temp]# ./copy 
real 0m31.915s 
user 0m0.050s 
sys 0m3.780s 

Тест #3: 
[serg@cherep temp]#./unpack 
real 0m35.084s 
user 0m19.260s 
sys 0m2.180s 

Тест #4: 
Запускаем с другой консоли copy1 для нагрузки диска. 
Заходим в /usr/src/linux-2.6.8.test 
make mrproper 
cp /mnt/all/.config /usr/src/linux-2.6.8.test/.config 
make oldconfig 
time make bzImage 
Получаем: 
Kernel: arch/i386/boot/bzImage is ready 
299.170u 31.160s 10:24.41 52.0% 0+0k 0+0io 2364358pf+0w 
Гасим copy1 
Заходим в /usr/src/linux-2.6.8.test 
make mrproper 
cp /mnt/all/.config /usr/src/linux-2.6.8.test/.config 
make oldconfig 
time make bzImage 
Получаем: 
Kernel: arch/i386/boot/bzImage is ready 
289.300u 19.230s 5:20.83 96.1% 0+0k 0+0io 2364358pf+0w 

Передовой представитель ветки 2.4. показал тут себя с лучшей
стороны 
5m20s - без нагрузки 
10m24s - с нагрузкой постоянного копирования. 

kernel 2.6.8.1 

Тест #1: 
[serg@cherep temp]# hdparm -t /dev/hda 
/dev/hda: 
Timing buffered disk reads: 160 MB in 3.02 seconds = 52.99 MB/sec 

Тест #2: 
[serg@cherep temp]# ./copy 
real 0m32.242s 
user 0m0.054s 
sys 0m3.941s 

Тест #3: 
[serg@cherep temp]#./unpack 
real 0m33.128s 
user 0m20.900s 
sys 0m2.804s 

Тест #4: 
Запускаем с другой консоли copy1 для нагрузки диска. 
Заходим в /usr/src/linux-2.6.8.test 
make mrproper 
cp /mnt/all/.config /usr/src/linux-2.6.8.test/.config 
make oldconfig 
time make bzImage 

И тут началась тоска. Все происходило медленно 🙁 
Получаем: 
Kernel: arch/i386/boot/bzImage is ready 
312.015u 29.249s 33:00.41 17.2% 0+0k 0+0io 20338pf+0w 
Больше чем полчаса!!!!! 
Гасим copy1 
Заходим в /usr/src/linux-2.6.8.test 
make mrproper 
cp /mnt/all/.config /usr/src/linux-2.6.8.test/.config 
make oldconfig 
time make bzImage 
Получаем: 
Kernel: arch/i386/boot/bzImage is ready 
312.469u 24.310s 5:18.20 94.0% 0+0k 0+0io 557pf+0w 
Тут все в норме. 

Видим результаты и чухаем голову 🙁 Почти в 6 раз быстрее без нагрузки на винт. 

Результирующая таблица 

Результаты: 

Видно, что 2.6. чуток пошустрее. Но работа с диском безбожно жрет ресурсы процессора. Там где ядра 2.4. справлялись за 10 минут, 2.6. понадобилось в три раза больше времени. Таки iowait тратится впустую некорректно отбирая ресурсы. Что-то не так в Датском королевстве. Это у меня один жесткий диск и быстрый проц - так что все не так критично. А у других: не каждый пользователь будет одновременно компилить ядро и перемещать большие массивы информации. Так что большинство этой баги даже не заметят и буду радоваться шустрости новой ветки. Но я себе представляю что будет когда начнут массово переводить серваки на новую ветку 🙂 Пол дюжины сказевников - никаких там дуалксеонов не хватит что-бы нормально
поддерживать работу Рэйд и прочих массивов дисковой подсистемы. Хорошая нагрузочка на такую машину - и там где ядра 2.4. спокойно себе держались 2.6. будут попадать в попу 🙂

Выводы: 

- Пока go-go-go на 2.4.27 
- Думать головой в чем все-же проблема 
- Подождать еще пару версий, мож че-то исправится в 2.6. 
- Есть еще дурная идея попробовать в исходники 2.6. подсунуть драйвера для ide из 2.4. 🙂 Интересно, скомпилится ли. 

P.S. А вот и первые ласточки 🙂 У народа начинают жутко тормозить серваки. 

http://forums1.itrc.hp.com/service/forums/questionanswer.do?admit=716493758+1096779815623+28353475&threadId=698048 
http://lkml.org/lkml/2004/4/16/153 
http://www.linuxquestions.org/questions/history/230630 

P.P.S. И напоследок самое плохое: 

http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-11/417index.html 

В конце прошлого года всплывала похожая проблема на 2.6.0test ядрах для каких-то конкретных сказевников.
В обсуждении участвовали: 
Пауль Вэнэйза у которого были проблемы с серваком на 2.6. 
Эндрю Мортон - имеет вроде некоторое отношение к разработке ядер и написанию патчей 
Линус Торвальдс - он самый, папа Линукса. 
Они там так ничего и не выяснили. Подумали что дело в драйверах именно для этих сказевников и пообещали наехать на разработчиков. Пауль Вэнэйза забил на все и откатился на 2.4.

Вот так вот 🙁 

P.P.P.S. дисковой подсистемой при работе рулит драйвер который компилится из 
/usr/src/linux-бла-бла-бла/drivers/ide/ide-disk.c 
Так вот, во всех 2.4. версия 1.17 или ниже. 
Во всех 2.6. версия этих ИДЕдров 1.18 или выше.
И самое западло в том, что не указано что нового в версии 1.18. 

Чего они там собаки понаписывали?