:: Моя борьба: бага в ядрах 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.

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