форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Здоровый iowait в 2.6."
Сообщение от Cherepulya (ok) on 29-Сен-04, 15:48  (MSK)
Перепробованы ядра - 2.6.5 из дистра FC - 2.6.8.1 самособранное - 2.6.8.1 + ac - с патчами от Алана Кокса - 2.6.9rc2 самособранное На любом из этих ядер дисковые операции (например копирование большого файла) зажирают все ресурсы проца (AXP3200+). ДМА включено. top демонстрирует такие вещи: CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle            total    4,7%    0,0%   15,3%   0,7%     0,7%   78,2%    0,0% Пробовалось на файловых системах ext3 и reiser На любом ядре 2.4.  все летает и шуршит. Дисковые операции отнимают не больше 10% ресурсов проца. Помогите понять в чем дело. Мну уже в отчаянии перепробовал все патчи на ядро и с болью в душе и сердце посматривает 2.4.28pre3   :(
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "Здоровый iowait в 2.6."
Сообщение от DeadMustdie (??) on 29-Сен-04, 20:11  (MSK)
По моим наблюдениям, описанная ситуация вызвана исключительно различиями подсчёта процессорного времени. То бишь в iowait в линейке 2.6 попадает то времячко, которое в 2.4 попадало в idle. Сие подтверждается несложным экспериментом: 1. Запускаем нечто вроде   dd if=/dev/zero of=BigFile bs=4096 2. Смотрим среднюю скорость увеличения размера файла - нечто вроде   while true; do ls -l BigFile; sleep 5; done 3. Запускаем жадную до процессора задачку, можно не одну:   while true; do false; done 4. Снова смотрим среднюю скорость роста файла - изменения практически отсутствуют (если, конечно, не запустить задачек из пункта 3 штук 10:). Если бы на ввод-вывод тратилось *реальное* время процессора, наверняка было бы видно замедление. Примеры вывода: 1. до запуска тормозной задачки: $ while true; do ls -l BigFile; sleep 5; done -rw-rw-r--    1 maxim    maxim    316456960 Сен 29 20:02 BigFile -rw-rw-r--    1 maxim    maxim    569540608 Сен 29 20:02 BigFile -rw-rw-r--    1 maxim    maxim    804769792 Сен 29 20:02 BigFile -rw-rw-r--    1 maxim    maxim    1195700224 Сен 29 20:02 BigFile -rw-rw-r--    1 maxim    maxim    1567682560 Сен 29 20:02 BigFile -rw-rw-r--    1 maxim    maxim    1829277696 Сен 29 20:02 BigFile -rw-rw-r--    1 maxim    maxim    2065133568 Сен 29 20:02 BigFile -rw-rw-r--    1 maxim    maxim    2405908480 Сен 29 20:03 BigFile -rw-rw-r--    1 maxim    maxim    2761338880 Сен 29 20:03 BigFile -rw-rw-r--    1 maxim    maxim    3037020160 Сен 29 20:03 BigFile -rw-rw-r--    1 maxim    maxim    3242741760 Сен 29 20:03 BigFile -rw-rw-r--    1 maxim    maxim    3607195648 Сен 29 20:03 BigFile -rw-rw-r--    1 maxim    maxim    3841122304 Сен 29 20:03 BigFile -rw-rw-r--    1 maxim    maxim    4100050944 Сен 29 20:03 BigFile -rw-rw-r--    1 maxim    maxim    4360843264 Сен 29 20:03 BigFile 2. и после: $ while true; do ls -l BigFile; sleep 5; done -rw-rw-r--    1 maxim    maxim    406700032 Сен 29 20:05 BigFile -rw-rw-r--    1 maxim    maxim    662454272 Сен 29 20:05 BigFile -rw-rw-r--    1 maxim    maxim    884535296 Сен 29 20:05 BigFile -rw-rw-r--    1 maxim    maxim    1277599744 Сен 29 20:05 BigFile -rw-rw-r--    1 maxim    maxim    1745657856 Сен 29 20:05 BigFile -rw-rw-r--    1 maxim    maxim    2052362240 Сен 29 20:05 BigFile -rw-rw-r--    1 maxim    maxim    2337181696 Сен 29 20:05 BigFile -rw-rw-r--    1 maxim    maxim    2496696320 Сен 29 20:05 BigFile -rw-rw-r--    1 maxim    maxim    2811600896 Сен 29 20:06 BigFile -rw-rw-r--    1 maxim    maxim    3156459520 Сен 29 20:06 BigFile -rw-rw-r--    1 maxim    maxim    3429195776 Сен 29 20:06 BigFile -rw-rw-r--    1 maxim    maxim    3588304896 Сен 29 20:06 BigFile -rw-rw-r--    1 maxim    maxim    3957764096 Сен 29 20:06 BigFile -rw-rw-r--    1 maxim    maxim    4293296128 Сен 29 20:06 BigFile -rw-rw-r--    1 maxim    maxim    4546600960 Сен 29 20:06 BigFile Вычисляем скорость: случай 1: (4360843264-1567682560) / 10 ~ 266 MB/sec случай 2: (4546600960-1745657856) / 10 ~ 267 MB/sec Итого: пугаться нечего.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "Здоровый iowait в 2.6."
	Сообщение от DeadMustdie (??) on 29-Сен-04, 21:54  (MSK)
	Поправочка: итоговые скорости нужно ещё поделить на 5 - интервал-то пятисекундный между ls-ами. Впрочем, на смысл это не влияет.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "Здоровый iowait в 2.6."
	Сообщение от Cherepulya (ok) on 02-Окт-04, 19:12  (MSK)
	Хех, провел я тоже тесты. Бралось несколько ядер 2.4. и 2.6.8.1 Нехитрым скриптом нагружался привод: cat copy1 time cp 1.avi 2.avi rm 2.avi ./copy1 Потом делал так time make bzImage При компилировании ядра скорость копирования практически не падала. Но зато ядра 2.4. справлялись с этой задачей в среднем за 10 минут 30 сек.  При загруженом ядре 2.6.8.1 при аналогичных условиях понадобилось больше 30 минут :( Таки жрет iowait ресурсы проца. P.S. Более детальные результаты выложу на форуме под именем ядра 2.4. vs 2.6.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.