IO - всё нереально тормозит

man hdparm, смотреть DMA-режим винта

renice + ionice для linuxdcpp.

У меня SATA, кстати.

__________________________________
sudo hdparm -d1 /dev/sda

/dev/sda:
 setting using_dma to 1 (on)
 HDIO_SET_DMA failed: Inappropriate ioctl for device
 HDIO_GET_DMA failed: Inappropriate ioctl for device
__________________________________
sudo hdparm -i /dev/sda 

/dev/sda:

 Model=ST9120821AS, FwRev=3.06, SerialNo=5PL37GZH
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=8192kB, 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 *udma6 
 AdvancedPM=yes: unknown setting WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode
__________________________________
dmesg | grep Direct-Acces
scsi 2:0:0:0: Direct-Access     ATA      ST9120821AS      3.06 PQ: 0 ANSI: 5
scsi 4:0:0:0: Direct-Access     Kingston DataTraveler 2.0 PMAP PQ: 0 ANSI: 0 CCS
__________________________________


вроде бы с ДМА всё порядке? (кроме того, что его нельзя установить)

Какой io-шедулер? Попробуй прикрутить bfq.

http://www.linux.org.ru/view-message.jsp?msgid=3632698

cat /sys/block/sda/queue/scheduler noop anticipatory deadline [cfq]

а за ссылку выше комраду спасибо, кстати.

Перелезь на i686 сборку. Сравнить.

трындец... Раньше как-то не особо обращал внимание, а в последнее время это стало таки задалбывать(материнская плата - nForce 410, винт Hitachi на 250Гб с NCQ). К тому же совсем по идиотски смотрится, когда когда к тебе заходит кто-то, видит всю эту херню, и выдает фразу мол "тю, таже херня что и в венде".

в общем, осилил все эти эпичные треды с бенчмарками сочувствующих и всё такое.

какого-то конкретного решения не предоставляется. выставить elevator=as или там установить нужный шелдер echo ... > /sys/block/sda/queue/scheduler и посмотреть на реакшн.

Короче говоря, у меня ничего не решилось. Отвечая на предпоследней комментарий, если бы на прошлом арче х86 были такие дикие тормоза, думаю, я бы заметил. Да и говорят вроде, что на х64 встречается чаще. На форуме убунте читал, что предположительно с выходом нового (хз какого там) это всё решилось, т.к. на лачпаде молчат.

попробовать bfq тоже было бы интересно. Только красноглазия не хватает с ходу удачно этим бфк пропатчить ядро, переставить модули, ну и всё такое. Надо почитать как там всё, пока времени нет.

>> какого-то конкретного решения не предоставляется.

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

>> если бы на прошлом арче х86 были такие дикие тормоза, думаю, я бы заметил

возможно у меня не настолько дикие, но картинка тоже не впечатляющая.

>> попробовать bfq тоже было бы интересно.

Таки решился на GPRS'е выкачать 57Мб сырцов нового ведра Х) Взял патчи BFQ, ща посмотрим что из этого получиться(если не глюканет арчевский PKGBUILD :)). Думаю о результатах в случаи чего в Talks'ах отпишусь, либо тут.

PS: как же я давненько ядро не собирал... последний раз вроде был после выхода 2.6.25

Собрал kernel-2.6.30 с gcc-4.4.0, включил флаг оптимизации для K8, изменил опцию SATA_NV, чтоб вкомпилить в ядро а не модулем. Включил BFQ. И как-то особой разницы не заметил. Даже при копировании папки с музыкой с одного винта на другой, работать с остальными приложениями немного затруднительно - грузится все довольно долго, интерфейс может подвисать ну и судя по гномовскому апплету - IO загружен под завязку.

Хм, то ли ССЗБ с GCC-4.4.0, то ли хз, но стал подвисать звук О_о Раньше при копировании файлов можно было просматривать видео, сейчас - местами банально дропаются кадры mplayer'ом. И почему-то в Guitar Hero III в wine во время игры музыка стала местами прерываться, хотя с 2.6.29 такого не было. Сколько не игрался с шелудерами - существенной разницы между cfq и bfq так и не заметил. Че-то я вообще весь расстроился :( У NVIDIA ничего окромя видеокарт не получается в Linux.

vegeek@vegeek:~$ uname -r
2.6.18-6-686
А что поделаешь-то?

эх... а мне будет проблематично откатиться, ибо качать снова сырцы овер 30Мб на GPRS...

ЗЫ: сейчас собираю ядро без опции оптимизации под K8, и фигею - Audacious заикается О_о

мда, ситуация хуже некуда. С любым шелудером в 2.6.30 проблемы. Музыку запустил без лишних процессов - местами заикается, а потом и вовсе перестает играть. mplayer играет постоянно, но дергается. Возможно эта трабла из-за gcc 4.4.0, но откатываться на 4.4.3 лень, т.к. gnutls и еще кое-чего завязано на новых gcc-libs в системе. Но I/O ничего не спасает вообще. Печально.

Те же проблемы. Дистр Арч i686.
Ядро 2.6.29 самосборное, планировщик anticipatory, файловая система xfs, чипсет интеловский

При сильной нагрузке на IO все начинает прилично тормозить. Не настолько печально как у выше отписавшихся, но неприятно.

Хм, может всё-таки нет эффекта из-за железа? У самого .30 + bfq + ext4 везде, компиляция ядра при -j 99 даёт вполне терпимые тормоза.

Стормозил... Мамка интеловская, винт -- идешный макстор.

>> При сильной нагрузке на IO все начинает прилично тормозить.

Надо бы какие-то тесты провести :) Просто понятие "сильная нагрузка" весьма растяжимое. Сейчас на ведре 2.6.29 параллельно приложения работают весьма сносно когда чего-то интенсивно выполняется(т.е. музыка играет без запинки, если к примеру мюксить mkv в пределах одного винта с помощью mkvmerge). Но запустить что-то новое - это таки проблематично. Фуррифокс при нагрузке на I/O работает вообще с трудом - процесс поиска при наборе адреса в адресной строке - это кошмар. Если тыкать по менюшке, так GUI и вовсе подвисает. Сейчас собираю опять ядро 2.6.30 без BFQ патча(57Мб жалко блин, надо ж разобраться до конца :)).

ЗЫ: читал про баг на kernel.org, что приводили VeGeek'у, так там у людей просто катастрофически низкая скорость была. У меня вполне нормально dd показывает ~50-60Mbps

>>Надо бы какие-то тесты провести :) Просто понятие "сильная нагрузка" весьма растяжимое. Сейчас на ведре 2.6.29 параллельно приложения работают весьма сносно когда чего-то интенсивно выполняется(т.е. музыка играет без запинки, если к примеру мюксить mkv в пределах одного винта с помощью mkvmerge). Но запустить что-то новое - это таки проблематично. Фуррифокс при нагрузке на I/O работает вообще с трудом - процесс поиска при наборе адреса в адресной строке - это кошмар. Если тыкать по менюшке, так GUI и вовсе подвисает.

Сильная нагрузка - копирование файлов десятка файлов в 2-3 гига размером с одного раздела на другой.

Примерно как ты описал. В текущем предложении работать можно, музыку не клинит, но при попытке переключения между окнами или открытия нового приложения - тормоза.

я подозреваю, что дело тут в железе и не хватает пропускной полосы шины данных. Скажи, какое у тебя первое число выводит hdparm -tT /dev/sda?

>>я подозреваю, что дело тут в железе и не хватает пропускной полосы шины данных. Скажи, какое у тебя первое число выводит hdparm -tT /dev/sda?

/dev/sda:
Timing cached reads: 2834 MB in 2.00 seconds = 1417.39 MB/sec
Timing buffered disk reads: 242 MB in 3.01 seconds = 80.35 MB/sec

отлично все с железом)

> Do you have queuing enabled on your drives? You can check that in
> /sys/block/sdX/device/queue_depth. Try setting those to 1 and retest all
> schedulers, would be good for comparison.

Если это улучшит ситуацию именно с cfq, то нужно ставить noop. Иногда на системах с NCQ она злобно интерферирует с алгоритмами планировщика

>> Если это улучшит ситуацию именно с cfq, то нужно ставить noop.

Я и вовсе отключал ncq по libata.force=noncq, но ситуацию это никак не спасало(только скорость копирования мелких файлов падала). Попробовал noop - никакой заметной разницы при все тех же операциях с копированием файлов, и пробой запуска других приложений, или работы с интерфейсом третьих. В общем единственное, что пока думаю - откатить версию gcc да попробовать снова собрать ведро версии 2.6.30 с BFQ, т.к. уж очень удивляет работа этой версии(звук через alsa банально запинается и перестает играть в Audacious, либо постоянно запинается в mplayer, в wine аналогичная ситуация с запинками).

Наблюдал похожее. Гребанный dc++ своим хешировнаием выедает ведь дисоквый io. Если много больших файлов - то ж@п@ до тех пор, пока операция не закончится. Как вариант - запускать linuxdc++ с самым фиговым приоритетом на io или в процессе ренайсить. man ionice.