[kernel][io][2.6.33-rc5] пропал глюк с io wait?!

и да

Например, тест по компиляции ядра показал, что время сборки практически >не зависит от FS

как ядро не знаю, а вот от фс сильно зависит сборка всего остального - в тмпфс заметно шустрее собирается :)

Sempron 2800+ (1x1.6ГГц), 1.5Гб, SATA, ext4 без журнала.

$ sync && bash -c 'echo 3 > /proc/sys/vm/drop_caches' && bash -c 'time emerge -pe world > /dev/null'
real 1m30.219s
user 0m49.078s
sys 0m1.807s

$ time emerge -pe world > /dev/null
real 0m58.093s
user 0m48.582s
sys 0m1.270s

nona frag # hdparm -tT /dev/sda7

/dev/sda7:

Timing cached reads: 2262 MB in 2.00 seconds = 1130.59 MB/sec

Timing buffered disk reads: 312 MB in 3.00 seconds = 103.99 MB/sec

щас переформачу /usr/portage в ext4 без журналирования и снова тесты прогоню

>103.99 MB/sec

Вот, вдвое быстрее, чем у меня а время работы без кеша ненамного быстрее. А с кешем - медленнее.

У меня тоже ICH9R и баг, насколько я понимаю, в наличии :/

У меня вообще какие-то странные результаты :)

/dev/sda5:
Timing cached reads: 6686 MB in 2.00 seconds = 3344.54 MB/sec
Timing buffered disk reads: 164 MB in 3.03 seconds = 54.10 MB/sec

Мой / на ext3

>я чего только ни пробовал для /usr/portage - везде тормоза безбожные

В основном тормоза из-за питона. Если ищешь самую быструю фс — это squashfs.

# mount | grep portage
/dev/loop0 on /usr/portage type squashfs (rw)
# grep squash /etc/fstab 
/var/cache/portage/portage.cache	/usr/portage		squashfs	loop 0 0
# cat ~/portage-sync.sh
#! /bin/bash

function die
{
	echo ${*}
	exit 1
}

umount /usr/portage || die "Umount failed"
cd /tmp || die "chdir to /tmp"
unsquashfs /var/cache/portage/portage.cache || die "Cannot unpack current snapshot"
mount -o bind /tmp/squashfs-root/ /usr/portage/ || die "Cannot mount squashfs image on /portage"
emerge --sync || die "Failed to sync"
umount /usr/portage || die "Umount"
cd /tmp/squashfs-root/ || die "WTF?"
mv /var/cache/portage/portage.cache{,.bak}
mksquashfs . /var/cache/portage/portage.cache -noappend || die "Cannot make archive"
cd
rm -fr /tmp/squashfs-root/
mount /usr/portage

В /tmp естественно tmpfs.

# sync && bash -c 'echo 3 > /proc/sys/vm/drop_caches' && bash -c 'time emerge -pe world > /dev/null'

real	0m13.895s
user	0m9.017s
sys	0m1.548s
# grep name /proc/cpuinfo 
model name	: Intel(R) Core(TM)2 Duo CPU     E6750  @ 2.66GHz
model name	: Intel(R) Core(TM)2 Duo CPU     E6750  @ 2.66GHz

Но это нерепрезентативно, т. к. world у всех разный. У меня, к примеру, в /var/lib/portage/world всего 60 строчек.

>В основном тормоза из-за питона.

Почему тогда paludis тоже тормозит, практически так же (специально не замерял, но разницы не очутил)?

>Почему тогда paludis тоже тормозит, практически так же (специально не замерял, но разницы не очутил)?

Попробуй, как будут различаться первый запуск (когда кеш еще не заполнен) и последующие (когда чтения с диска нет). На мощных процессорах различия огромные. На стареньком P IV очень много времени уходит на сам питоновский emerge.

Ну и хотелось бы заметить, что firefox тоже на C++ написан, но запускается непозволительно долго.

>Но это нерепрезентативно, т. к. world у всех разный

действительно

>Ну и хотелось бы заметить, что firefox тоже на C++ написан, но запускается непозволительно долго.

Ну, чуть выше ссылку давал - http://balancer.ru/tech/forum/2009/05/t64670--ocherednoj-bench-proizvoditelno...

Время запуска firefox при /usr на разных ФС тоже разное :)

демон, что ты мне насоветовал??

# sync && bash -c 'echo 3 > /proc/sys/vm/drop_caches' && bash -c 'time emerge -pe world > /dev/null

real 9m28.853s

user 6m41.993s

sys 1m5.960s

о, второй раз лучше:

real 1m16.695s user 0m54.846s sys 0m0.379s

$ time emerge -pe world > /dev/null

real 0m55.449s

user 0m53.920s

sys 0m0.332s

это всё ext4 без журнала

>real 9m28.853s

Это на чём так?? :)

ext4 без журнала

Очень странно. (В моём тесте - с журналом)

но рад, что починили ACPI

А это кому как знаете ли... У меня как в *.32 сломали так до сих пор(33-rc5) никаких изменений.

А у меня вот при обновлении дерева портежей были жесткие фризы. /usr/portage в ReiserFS.