http://lkml.org/lkml/2010/11/12/344

Насколько я понял, эта версия не самая оптимальная, но скорость чтения поднимает в 1.4 раза на четырёхядерном процессоре, скорость записи - до 2-х с лишним раз быстрее. Поддерживаются шифрованные разделы поверх шифрованных разделов. Да, тест в сообщении был с CFQ, говорят для dm-crypt сейчас это не самый оптимальный шедулер ввода-вывода.

Что-то не везёт мне с udev-ом. Собрал самую новую версию, из git (http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=560de575148b7efda3... - Use ata_id, not scsi_id, on ATAPI devices), через немного подпиленный SlackBuild - всё равно при старте не было правильной группы на /dev/hda (cd-dvd-rw привод). Путём манипуляций с копированием 50-udev-default.rules, 60-cdrom_id.rules в /etc/udev/rules.d и псоледующим редактированием на предмет замены sr* на hd* там где было что-то про cdrom, плюс добавил в 50-udev-default.rules ATTRS{media}==«cdrom» в соответствующее правило:

--- /lib/udev/rules.d/50-udev-default.rules 2010-11-05 23:35:57.000000000 +0300
+++ /etc/udev/rules.d/50-udev-default.rules 2010-11-06 02:42:53.000000000 +0300
@@ -75,7 +75,7 @@
SUBSYSTEM==«block», KERNEL==«fd[0-9]», GROUP=«floppy»

# cdrom
-SUBSYSTEM==«block», KERNEL==«sr[0-9]*», SYMLINK+=«scd%n», GROUP=«cdrom»
+SUBSYSTEM==«ide», KERNEL==«hd[0-9]*», ATTRS{media}==«cdrom», SYMLINK+=«cdrom%n», GROUP=«cdrom»
SUBSYSTEM==«scsi_generic», SUBSYSTEMS==«scsi», ATTRS{type}==«4|5», GROUP=«cdrom»
KERNEL==«pktcdvd[0-9]*», GROUP=«cdrom»
KERNEL==«pktcdvd», GROUP=«cdrom»


--- /lib/udev/rules.d/60-cdrom_id.rules 2010-11-05 23:35:57.000000000 +0300
+++ /etc/udev/rules.d/60-cdrom_id.rules 2010-11-06 02:04:21.000000000 +0300
@@ -2,10 +2,10 @@

ACTION==«remove», GOTO=«cdrom_end»
SUBSYSTEM!=«block», GOTO=«cdrom_end»
-KERNEL!=«sr[0-9]*|xvd*», GOTO=«cdrom_end»
+KERNEL!=«hd*|xvd*», GOTO=«cdrom_end»
ENV{DEVTYPE}!=«disk», GOTO=«cdrom_end»

-KERNEL==«sr[0-9]*», ENV{ID_CDROM}=«1»
+KERNEL==«hd*», ENV{ID_CDROM}=«1»
IMPORT{program}=«cdrom_id --export $tempnode»

LABEL=«cdrom_end»


Но после этого /etc/rc.d/rc.udev reload не помогло, а вот после запуска udevadm test /devices/pci0000:00/0000:00:11.1/ide0/0.0/block/hda (путь был найден запуском udevadm info -q path -n /dev/hda) всё нужные симлинки появились, группа для /dev/hda - «cdrom», не дефолтный «disk». Соответственно k3b работает.


Кто-нибудь может проверить, дефолтный udev-164 (или лучше - git-версия) на ядре с old deprecated ATA drivers тоже имеет косяки с ide cd-rom/rw ?

http://blog.martin-graesslin.com/blog/2010/10/optimization-in-kwin-4-6/

Обещают ускорение работы фильтра Lanczos, который сильно усложняет жизнь пользователям в 4.5 (фильтр не будет фильтровать все окна на экране, а только те, которые нужно). Обещают ускорение работы этой прыгающей анимации «приложение сейчас, вот-вот, ещё-чуть-чуть, запусти-и-ится». (которая с какого-то перепугу раньше превращалась в RGB окно без альфа-канала). Из общего есть (ну, или должно быть в trunk) кэширование текстур и геометрических данных, использование TFP (texture-from-pixmap, блин, а раньше-то они через что делали?! ЭТо TFP уже четыре года как известно .....) что должно избавить от медленных преобразований между QPixmap/QImage. Эффекты трансформации _одного_ окна вызывали перерисовку _всего_ экрана. Должно быть «фиксед», в новой версии. Правда, все плагины придется переделать, один за одним, чтобы получить желаемый эффект.

Тема «ускорить blur-эффект» оставлена примерно до 4.7

Итак, продолжая злостные эксперименты, собрал udev-153 с патчем

http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=665ee17def2caa6811...

«udevd: always try to find an idle worker instead of forking a new one»

(на новый удав - новые грабли наступать пока не охота)

Но это не помогло - на моём достаточно модульном конфиге сразу после старта udev всё замирает, с mem=32m. С mem=36m - идет до текстового логина, как и положено. Workaround с ранним подключением физического своп-файла не очень хочу использовать, ибо тормоза, а виртуально-сжатый через zram не очень-то и помогает, на таких малых объемах памяти. Отсюда вопрос: а что делает ваша система, если попытаться её загрузить с такими же параметрами: mem=32m ?

Может у кого из местных пользователей radeon проблема вылезала, в баге обсуждают подвисания машины в как-бы случайном порядке, в ходе нормальной деятельности (firefox там. .... ).

Кажется, в логике работы с чипами, где vram < pci bar size была ошибка, приводящая к этим подвисаниям. У меня карточка с такими же параметрами (64 vram, 128 PCI BAR) - но вроде особых подвисаний за пару дней не видел. Кто хочет - может потестить последний патч, https://bugs.freedesktop.org/attachment.cgi?id=39651 а я пока подумаю, как бы подвесить свою машину, м.б. agpmode=-1 поможет.

http://www.liveinternet.ru/users/ilya_chernykh/post129345101/

Выглядит оно конечно хорошо, но есть вопросы:

1. Оно же на qt2. Патчи по безопасности на это вроде уже никто не делает, как и на сам KDE2 ?

2. Управление оборудованием: xrandr 1.2, энергосбережение, управление частотой процессора .... ? Из GUI, имеется в виду. Кто-то эту функциональность добавляет, как для Trinity ?

3. Автоопределение подключаемых устройств, удобное задание опций монтирования? (на КДЕ3 на это дело патч был, не принятый в свое время в основную ветку. Ибо слишком много элементов управления добавлял, для stable это считалось неприемлемо.)

4. Эпичные баги ? :}

После собственноручного обрушения бОльшей часть КДЕ-шных прог - пересобрал их заново на своей (почти) -current Slackware.

Среди прочего был k3b 1.0.5

Он с некоторых пор повадился подвисать при проверке DVD проекта. Вот баг. http://bugs.kde.org/156684

В нём , в комментарии 30 есть патч. Но я его не использовал, а использовал другой, отсюда:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-cdr/k3b/files/?hi...

k3b-1.0.5-eject_186173.patch

Вроде бы маленький проект записал и проверил нормально. Если кто-то ещё использует старый k3b для KDE3 - отпишитесь, какой из патчей у вас работает лучше?

Там ffmpeg патчи ещё есть, для них я запускал autoconf, а для нового autoconf-2.64+ оказывается нужен патч, примерно как тут:

http://developer.berlios.de/bugs/?func=detailbug&bug_id=16635&group_id=4482

http://git.altlinux.org/people/drool/packages/?p=sim.git;a=blob;f=sim-0.9.5-f...

На самом деле сейчас этот патч уже в svn репозитарии sim-im (я побаивался оттуда обновляться - но там к счастью оставили старый код для КДЕ3, не выкорчёвывая его поддержку, а всё новое переехало куда-то на mercurial )

ПС: придётся-таки через какое-то время переезжать на КДЕ4 проги, сам-то кде3 в виде ТДЕ продолжает развитие, как я смотрю, но вот все дополнительные внешние проги (k3b, digikam, нелинейный видеоредактор ) - всё уехало на qt4/kdelibs4 :/ А оно и места ест больше, и компилируется дольше, и внешний вид не в моём вкусе, по крайней мере дефолтный.

Поставил я себе во флаги --param ggc-min-expand=0 --param ggc-min-heapsize=8192 , и пересобираю gentoo system потихоньку, почти 4 дня.

И тут на libxml2 смотрю - cc1 аж 150 минут (!) думал над файлом. Посмотрел размер файла - 800 кб. Восьмьсот килобайт. Сишного кода с комментариями. И он там не один такой. Пожалуй, ggc-min-heapsize надо было побольше поставить..... Зато даже под конец компиляции virt для cc1 не вылез за пределы 30 Мб, а res - за 24 мб.

Но - 800+ килобайт КОДА .... я просто сражён на повал. Даже в ffmpeg такого безобразия нету:

du -h source/mplayer/ffmpeg/libavcodec/dsputil.c
164K source/mplayer/ffmpeg/libavcodec/dsputil.c


du -h source/mplayer/ffmpeg/libavcodec/mpegvideo_enc.c
144K source/mplayer/ffmpeg/libavcodec/mpegvideo_enc.c

А это чудо ...
http://svn.gnome.org/viewvc/libxml2/trunk/xmlschemas.c?view=log
File length: 816925 byte(s)

Будет кстати забавно, если portage отфильтрует эти параметры для того компонента, которому они предназначались : gсc и его жадному до памяти genattrtab.

Да, компилится оно на mips r5k, 180 Mhz. На виртуальных хостингах (откуда ноги у конкретных значений и растут, как я понял) наверное всё гораздо быстрее.

В общем, если и сам gcc параметры эти использует при своей компиляции - это будет очень здорово, значит даже относительно слабая машина (по всем параметрам сразу - ЦПУ, память, диск) как минимум в состоянии скомпилировать даже большой С проект. Я уж опасался, что на 64 Мб gcc4 вообще не жилец. Оказалось, его просто подтюнить надо. Хотя наверняка узнаем только завтра.

Решил недели две назад обновить систему на своей SGI O2 (mips). Сказано - поехали! Поскольку машина по скорости компиляции в 6 примерно раз медленее моего десктопа (на котором Slackware), а он в свою очередь примерно в 8 раз медленее среднего прошлогоднего AMD Barton 2300BE (кажется так, уж не помню точно, друг давал машину на время) - то просто «пересобрать всё» выглядело ну очень утомительным процессом. Решил обновлять пакеты по-одному, или небольшими группами. Успешно обновил gcc до 4.4.4 (почти словив OOM, сейчас почитал http://hostingfu.com/article/compiling-with-gcc-on-low-memory-vps , добавил эти параметры, ещё раньше убрал -pipe из CFLAGS). Успешно обновил большую часть media-libs, скомпилировал audacious и GIMP-2.6.10 (размаскировав оба). Audacious играет, правда процентов 40-45 от mips r5k/180Mhz/512K L2 ест. ладно, поставлен был «для красоты» (ну и посмотреть, соберётся ли). ГИМП оказался тоже достаточно рабочим для создания скриншота, как минимум (http://img196.imageshack.us/img196/8307/gimp2610mips1.jpg). Правда, для него пришлось пересобрать pygtk/pyobject , а для них - numpy (от количества warnings в котором мой экран скроллился несколько раз, при emerge предупреждения фиксируются и потом отдельно выдаются на экран, мол не приставайте к нам с багами, бегом на страницу проекта, который так код пишет.).

И всё было хорошо, пока я не стал пересобирать gtk+ . Оно вывалилось с ошибкой, оказалось при апгрейде libpng 1.2 -> 1.4 я забыл запустить прилагаемый скрипт, который в свою очередь хотел portage-utils, которые пришлось поставить. В общем странное осталось ощущение - простейшие операции _специально_ не автоматизируются, видимо чтобы админ не спал, а читал что ему пишут на экране. Ладно, обновил gtk - обновлю и X сервер! Обновил ... правда, несмотря на обычную тщательность (просмотр вывода emerge -p , установка USE флагов по необходимости) пропустил казалось бы безобидное обновление udev. X-то запустились, правда конфиг был не тот немного, и они проигнорировали «устаревшие» драйвера kbd/mouse. ладно, ребут .... И тут отваливается udev. Не очень страшно, если грузишься по сети, и вся система - на NFS. Нашёл казалось бы решение - нужно пересобрать glibc с новыми kernel-headers (2.6.35 поставил, вместо старых 2.6.24). Стал пересобирать ... Правда, меня предупредили на #gentoo-mips, что апгрейд до 2.11.2 может вылиться в сегфолт. Ну, я сделал quickpkg для текущей glibc, и полный бэкап всего, что было на NFS root.

Обновив glibc - нарвался на сегфолты, почти всего, начиная от gawk и заканчивая gcc. Обидно, но emerge работает. Указываю ему на /usr/portage/packages/sys-libs/glibc-версия.tbz2 - ругается что «install by path is broken!» а потом вообще отказывается делать downgrade! (т.е. вернуться на старую версию glibc). Пришлось делать emerge --unmerge glibc (оно оказалось даже не в защищенных), потом tar'ом распаковывать архив-пакет со старой glibc, и водворять её на место (это на NFS сервере). Гружусь, emerge работает, предлагает поставить glibc. Умно. Маскирую новую версию glibc, заодно с udev-162. На этапе компиляции выясняется, что куда-то потерялся /usr/lib/crt1.o Ого. Достаю его из полного бэкапа (который на x86 машине, в виде squashfs4-образа, который достаточно смонтировать). После полусуток компиляции (из которых часа 2 генерились локали - надо бы это поправить ....) кажется получил рабочую glibc-2.9

Стал пересобирать систему. Но сначала пришлось мигрировать на openrc. А для этого пришлось пересмотреть кучу файликов (сорок), которые etc-update посчитал устаревшими. В большинстве случаев их можно было спокойно заменить, устаревший вариант на новый. В двух случая оставил старые настройки. Наверное, такая пляска была бы в любом дистре, захоти я его после почти полугода простоя обновить.

Openrc на этой медленной машине действительно грузит систему заметно быстрее, но не уверен что произойдёт, если он отвалится, по какой-то причине (glibc опять ....). Всё-таки поддержание gentoo в рабочей форме требует усилий, на быстрой машине это не так заметно, а тут .... две недели и всё ещё не обновился толком. Правда, и засады с glibc на x86 как я понимаю нет, да и на mips она не везде проявляется.

https://bugs.gentoo.org/show_bug.cgi?id=340243 - в эту багу мне предлагали отписаться, но я пока дождусь результатов emerge system, для glibc-2.9 А потом можно ещё один образ сделать, и экспериментировать с glibc-2.11

В общем хорошо конечно, что хоть один дистрибутив поддерживает старые SGI машины. И хорошо что системный компилятор до сих пор компилирует себя на 256 мегабайтах оперативки без свопа. Но всё же я всерьез начал думать о distcc .....

Эх, знатные флеймогоны там собрались, не хуже чем тут.

Однако среди флейма попался забавный результат - у кого-то OpenArena выдает под 100 fps на открытом r600c драйвере, в разрешении 2560*1600 (!)

-----
http://www.phoronix.com/forums/showpost.php?p=151088&postcount=132

А ниже - ещё более снногсшибательный результат - почти 200 fps в 1680x1050!

http://www.phoronix.com/forums/showpost.php?p=151133&postcount=136

Причем в последнем тесте именно r600g выигрывает, хоть и немного, у «классики».

Это все с патчем для отключения vsync в 2D драйвере и последний результат с включением 2d tiling (отключен в коде по-умолчанию, артефакты на _некоторых_ карточках).


200 фпс - это уже некоторый запас мощности для AA (которого пока нет, но как будет - сразу своё отгрызёт).


Но история (git history) показывает, что буквально несколько коммитов могут изменить ситуацию с «одна десятая скорости старого драйвера» до «превосходит по скорости старый драйвер». Причём ситуация зависит от того, встроенная карточка или нет (буфер с данными из дискретной видеопамяти читается на топовых и даже средних картах намного быстрее, чем из системной по PCI-E, пропускная способность памяти там пиковая до 130 Гб/С, но даже более умеренные 56-64 гб/c куда больше, чем на интегрированно видео, шарящем системную память.)

Поэтому мораль проста: прежде чем сказать «тормозит!» - не забудь обновиться .....

Г. Мильке. Путь в космос. Проблемы полёта в мировое пространство.
Перевод с немецкого Е.Н. Греченко, И.А. Крупенниковой, В.Ф. Прохорова.

Под редакцией И.М. Ильичевой.

Из-во иностранной литературы, Москва, 1959.

---------------------

Книга простенькая, «без формул». Но илл. в наличии.

http://foto.mail.ru/mail/randrik/71/ - маленькая часть указанных иллюстраций.

SWrast, даже не llvmpipe!

http://img62.imageshack.us/i/swrastberyltfp.jpg/



guest@slax:~$ glxgears
Mesa: CPU vendor: AuthenticAMD
Mesa: CPU name: AMD Duron(tm) Processor
Mesa: Mesa 7.9-devel DEBUG build Jun 13 2010 04:24:04
Mesa warning: software DXTn compression/decompression available
Mesa: MMX cpu detected.
Mesa: 3DNow! cpu detected.
149 frames in 5.0 seconds = 29.766 FPS

Так что не-тормозящая на vesa mac OS X почти побеждена, осталось найти почему не работает emerald, как можно заметить декораций окон нет.

Отличный пост, о том что именно пользователи своим ранним тестингом позволяют выявить регрессии _без выделения огромных дополнительных ресурсов_. Наш путь, короче.

http://www.phoronix.com/forums/showpost.php?p=130837&postcount=74

https://bugzilla.kernel.org/show_bug.cgi?id=12309

Копирую сюда свой setup

0. Model=ST3160021A системный + Model=SAMSUNG SP0802N дополнительный
1. «старом» ide 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06),
2. без эмуляции (НЕ через libata),
3. драйвер вбит в ядро,
4. 250 hz таймер,
5. без preempt,
6. проблем с прерываниями (irq storm) нету,
7. процессор старый одноядерный K7 (нет изменения частоты),
8. памяти 768 Мб, но можно сделать сколько надо.
9. FS: ext3 mode=ordered + XFS
10. CFQ везде.
11. ванильное 2.6.34-rc5

http://forums.ps2dev.org/viewtopic.php?t=10156&postdays=0&postorder=asc&start...

http://sourceforge.net/projects/kernelloader/files/ (235.5 MB)

Говорят, должно работать без modchip-а. (но есть странные проблемы с X-ами, неправельный modeline?).

http://kernelloader.cvs.sourceforge.net/viewvc/kernelloader/BlackRhino/src/x/... - вот

http://www.ptlsim.org/index.php

Говорят, что моделирует x86/x86-64 очень аккуратно, с динамическим изменением уровня детализации.

PTLsim is licensed under the GNU General Public License, version 2

Я лично про него раньше не слышал, поиск на LOR-е - тоже.

http://lkml.org/lkml/2010/5/3/404

для 2.6.33 указана скорость записи в 1.5 Мб/с Подкручивание /proc/sys/vm/dirty_bytes до 16000000 увеличивает скорость до 9-12 Mb/s. Задаётся вопрос - а можно эту настройку VM на отдельный класс устройств менять (кажется, таким специфическим поведением обладают только usb-флэшки)?

r300g (Gallium3D) победил, без шансов.

http://www.phoronix.com/data/img/results/gallium3d_llvmpipe/1.png

судя по этому графику, в 800x600 связка ATI Radeon X1950PRO 256MB + Intel Core i7 920 (2.66GHz O/c до 3.60GHz) побила барьер в 200 фпс в OpenArena 0.8.5! Стандартный драйвер r300 почему-то сумел лишь 125 прмерно выжать. Дальше стало лучше - в 1024x768 r300g - 140 fps, r300c - 60 примерно. И пока классический драйвер оставался на том же уровне примерно в 60 fps вплоть до 1920x1080 - к нему сверху медленно спускался график галлума, но даже в конечной точке разница была примерно 80 fps против 50.

да, llvmpipe на таких разрешениях естественно не больше 10 кадров в секунду делал, но в 800x600 свои обещанные 35 кадров/c выдал.

link:

http://lkml.org/lkml/2010/4/5/237

Под постоянной нагрузкой на запись она (XFS) в последних rc убьётся об OOM-killer'а. Я на этот баг наткнулся. И простое du выдувает XFS туда же, на некоторых конфигурациях.

Патчи в процессе производства.

в .35 наверное опять раснесут эту ФС на кусочки - обещают переделать систему записи лога, что должно на порядок поднять производительность с кучей мелких файлов.

http://xfs.org/index.php/XFS_Status_Updates

XFS status update for March 2010 «Using the new delayed logging mechanism I/O bandwidth used for the log decreases by orders of magnitude and performance on metadata intensive workloads increases massively. »

Итак, вот что получается для открытого драйвера вот отсюда

http://repo.or.cz/w/mesa/mesa-lb.git
* stable+testing

commit 6a74f1a6b171fc26cfe09b6c4bd0369bf7a6d2f8
Author: Luca Barbieri <luca@luca-barbieri.com>
Date: Fri Feb 26 02:09:07 2010 +0100

nvfx: nv40 fragment program control flow


репо почти мертвое, потихоньку патчи оттуда переезжают в основной репозитарий mesa.

Однако-ж:

guest@slax:~/source/mesa/progs/demos$ ./engine
libGL: OpenDriver: trying /mnt/hdd2/src-aux/mesa-nouveau-fixed-func/mesa-lb/lib/gallium/nouveau_dri.so
allocated 65536
0x8caf7b0: new fpbo!
allocated 131072
vp: GENERIC[0] to fpreg 4
adding relocation at 0 for 0
fp: GENERIC[0] from fpreg 4
0x8cc29e8: new fpbo!
allocated 196608
allocated 262144
242 frames in 5.023 seconds = 48.178 FPS
294 frames in 5.022 seconds = 58.542 FPS
294 frames in 5.012 seconds = 58.659 FPS
314 frames in 5.005 seconds = 62.737 FPS
274 frames in 5.015 seconds = 54.636 FPS

mesa из git master даёт картину вида
guest@slax:~/source/mesa/progs/demos$ ./engine
29 frames in 5.068 seconds = 5.722 FPS
33 frames in 5.143 seconds = 6.416 FPS
32 frames in 5.052 seconds = 6.334 FPS

Там довольно сильно пришлось покорёжить галлиум, но потенциал показан, надеюсь. Это на GF6200/AGP, на самом стартовом (медленном) уровне работы GPU.

Да, и это единственная карточка, которая _у меня_ есть и на открытых дровах делает

OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NV4A
OpenGL version string: 2.1 Mesa 7.9-devel
OpenGL extensions:

Так что если _сейчас_ Gallium-based дрова не шибко быстрые - это не значит что их вообще нельзя ускорить. Можно. Другой вопрос, что втиснуть несколько поколений железа от разных производителей под несколько разных API, зная что придётся это всё расширять до OGL3/4 .... непросто.