нагрузка на hdd затормаживает видео по сети

Видел где-то в lkml сообщения о том, что ядро (некоторые "бажные" версии) может при сильном io load начать вытеснять в swap образы программ (в моем случае X или граф. терминал).
Второе соображение - другие ресурсы не заняты и/или не конфликтуют, а винт забит нагрузкой в потолок и на нём кроме корня живёт swap, любой доступ к которому от этого сильно затормаживается.
Памяти действительно много, и в любом случае объём своппинга должен быть маленьким, но пока склоняюсь именно к этой гипотезе.

Update: ссылки на lkml
http://osdir.com/ml/linux-kernel/2009-05/msg06997.html
http://osdir.com/ml/linux-kernel/2009-05/msg07020.html

Начало снова воспроизводиться, пока в меньшем масштабе - секунда или меньше замерзания.
swapoff -a - особо не влияет, значит правда не swap, по крайне мере не только он
твик запуска acroread (ACRO_ENABLE_FONT_CONFIG 0) отсюда http://forums.adobe.com/message/1784155#1784155 - на наличие лага не влияет, но немного сокращает его
Подожду пока достигнет нескольких секунд, можно будет детальнее промониторить что-нибудь.

Пока писал дождался - попереключал планировщики и получил свой тормоз в несколько секунд :)) swapoff по-прежнему не влияет, ACRO_ENABLE_FONT_CONFIG 0 делает лаг коротким.
Запустил strace -c -tt -o output.txt до и после фикса acroread

До:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
99.78 0.010012 278 36 18 wait4
0.22 0.000022 1 26 8 stat
...
System call usage summary for 32 bit mode:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
59.25 0.000868 0 13250 1727 read
17.47 0.000256 2 167 munmap
15.22 0.000223 5 46 1 writev
...

После
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
52.78 0.000019 1 36 18 wait4
47.22 0.000017 0 51 read
...
0.00 0.000000 0 388 mmap2
...
100.00 0.001465 36039 2776 total

System call usage summary for 32 bit mode:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
28.64 0.000313 0 6924 3681 open
26.99 0.000295 0 631 26 readv
16.47 0.000180 0 1092 time
...
3.29 0.000036 0 13910 2339 read
...
0.00 0.000000 0 3281 mmap2
...
100.00 0.001093 56064 6239 total

В целом пока ничего интересного

Зачитывание .so-шек, видных в strace не помогло, причём их оказалось всего 44M.

CONFIG_PREEMPT - так же не помог, выбирал "low latency desktop"
$ zgrep PREE /proc/config.gz
# CONFIG_PREEMPT_RCU is not set
# CONFIG_PREEMPT_RCU_TRACE is not set
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_DEBUG_PREEMPT=y
# CONFIG_PREEMPT_TRACER is not set

>>но хочется понять чем именно он курочит систему

ИМХО неоправданной нагрузкой на проц. Вам же top wait показал 31%. Тоесть треть простоя. Плюс значительные потери на исполнение 32х разрядного кода вперемешку с 64 разрядным. При прокрутке видео основной тормоз в пропускной способности шины. Данные хоть и с сети, но как-то должны попасть на ЦПУ для распаковки, а затем их по той же шине послать в видеокарту. Интересно, что в момент тормозов показывает консолька мплеера, и пробовали ли вы отбрасывать фреймы опцией -framedrop. Ну и плюс к тому видео у Вас радеон. Автор мплеера их как то недолюбливает. Да и прикрутить ускорение на радеон покамест штука нетривиалная( иксы последние, куча библиотек и опций в xorg.conf, проблемы с одновременным 2 и 3d ускорением, особенности различных моделей плат и много чего еще).