|
Създаване на по-бързо и устойчиво ядро
|
|
|
|
|
|
от Димитър(19-09-2002)
рейтинг (16)
[ добре ]
[ зле ]
Вариант за отпечатване
Това е резюме на моите опити да създам по-бързо ядро
2.4.18/19, без да разбирам в дълбочина от C и асемблер.
Причината, която ме накара да се впусна в това приключение
е
съобщението на Никола Антонов във форума на
linux-bg.org
за учудващото бързодействие на варианта на Линукс ядрото,
разработено от МандрейкСофт за версия 8.2 на тяхната
дистрибуция. Това ме амбицира да се опитам да създам
подобно, което да облекчи моя стар компютър, реколта
'99г.
Започнах с преглед на опциите на gcc -О2 и -О3 -> man
gcc.
След това компилирах нетфилтър, сменяйки `COPT_FLAGS` във
Маkefile-a на -О3. Инсталирах по следния начин (местата на
нетфилтър са различни за всяка дистрибуция, моля проверете
как е при вас):
make KERNEL_DIR=/usr/src/linux BINDIR=/usr/sbin
LIBDIR=/usr/lib
MANDIR=/usr/man && make KERNEL_DIR=/usr/src/linux
BINDIR=/usr/sbin LIBDIR=/usr/lib MANDIR=/usr/man
install.
Така припокрих старите версии на нетфилтър и не се наложи
да трия ръчно или през pkgtool. Продължих с избор на опциите
на ядрото чрез make menuconfig.Указах само нетфилтър за се
изгради модулно. Остатъка включих като твърдо ядро.
Започнах да експериментирам с добавяне на -O2/-O3 във
/usr/src/linux/Makefile и компилиране.
След много опити и грешки, уцелих точната подправка - в
/usr/src/linux/Makefile, измених реда CFLAGS_KERNEL на
CFLAGS_KERNEL = -funroll-loops -O2. Това оптимизира
логическите операции в ядрото изискващи повтарящ се цикъл от
изчисления; големината и възможностите му.
Компилирах: make dep && make clean && make bzImage && make
modules && make modules_install.
Редактирах /etc/lilo.conf, описах новото ядро, рестартирах
последователно лило и компютъра - /sbin/lilo &&
/sbin/reboot.
Пуснах новото ядро в действие: резултатът беше намалена
употреба на памет до 50МВ при зареждане,
увеличено бързодействие с ~ 1/5 по моя преценка, 0% употреба
на суапа.Направих и друг експеримент за издръжливост -
пуснах Х,компилиране на ядро,музика,john и следене на
процесите едновременно.XMMS взе да насича в определени
моменти, обаче останалати задачи продължиха без проблем.
Динамиката на свободната памет бе между 4 и 17 МБ в
определени моменти, натоварването на процесора между 30 и
90% за потребителски процеси; средното натоварване - 2.30,
2.29, 1.88, минимално
използване на суап паметта.
Компилирах ново ядро 2.4.19 със същите параметри
`CFLAGS_KERNEL = -funroll-loops -O2`. За мое удивление,
старата кутия се справи за 30 минути вместо за 60.
Предполагам, че на по-нови машини с нови процесори,
SCSI/Ultra ATA дискове и с надстройка с hdparm ефектът ще е
много по-мащабен.
Eто и подробностите:
Операционна система:
Slackware Linux 8.1, kernel 2.4.18/19, ReiserFS,
glibc-2.2.5-i386-3, gcc-2.9.5-3-i386-2
Хардуер: Celeron 333 Мhz, MB:i440BX, 196 RAM, video: 8МВ
TNT2, Quantum CR disk 5400 RPM.
Последни бележки: Ако искате да ползвате драйверите от
Nvidia за ядрото, е добре да ги включите в него, а след това
да напишете наново make в директорията
NVIDIA_kernel-1.0.xxxx. Така хем конзолата с фреймбуфер ще
има по-добра графика, хем Х сървъра няма да се оплаква, че
не може да си намери драйвера `nvidia`.
Страничният ефект от употребата на NVdriver e вероятността
от замръзване на машината при превключване на конзолите с
Ctl+Alt+F*. Поне така се получаваше при мен, когато
преминавах в друга конзола и после трябваше да се върна към
графичен режим.
Затова е по-добре, ако можете да използвате драйверите,
които идват с ядрото и XFree86. Може да не са толкова добри,
както тези на Nvidia, но поне няма машината ви няма да
замръзва при превключване на конзолите. Ако много държите да
работите с драйверите от Nvidia, тогава терминални емулатори
като xterm, rxvt, console,shell и други са вашето спасениe,
докато ползвате XFree.
Ще се радвам, ако чуя дали моят опит дава положителни
резултати:
Пишете във форума дали има ефект.
Поздрави,
FreeJak,
17 септември 2002
<< Журналната файловата система ext3 | Кратко ръководство за писане на Bash скриптове >>
|
|
|
|
|
Веднага се хванах да пробвам.
От: Никола Антонов <linux (a) logos< dot >goto< dot >bg>
На: 19-09-2002@14:08 GMT+2
Оценка: 1/НеутраленВеднага реших да опитам твоя експеримент. С подобна конфигурация съм - Celeron 366 (форсиран на 460), 128 RAM, HDD 20 Gb 5400 rpm, 2 Mb cache, NVidia Vanta 8 Mb, Debian 3.0, Kernel 2.4.19, gcc 3.0.4 (всичко необходимо за работата на системата е вградено в ядрото, като модули са компилирани само нетфилтърът и nls). Използувах твоята опция. Засега единственият обективно очевиден резултат е, че имиджът на ядрото от 970 Kb стана 1050, т.е. малко повече от мегабайт. За останалите резлутати ще трябва да мине малко време. Веднага ще постна каквото забележа.
Поздравявам те за оригиналния подход, тепърва трябва да започнем експериментите:)
[Отговори на този коментар]
Никаква употреба на суап
От: Никола Антонов <linux __@__ logos__dot__goto__dot__bg>
На: 19-09-2002@14:20 GMT+2
Оценка: 1/НеутраленИзключих овърклокинга, и без това беше само експериментален (да видя докъде стигат възможностите на този процесор, при които може да компилира, без да се чупи компилацията). На този етап, следейки нещата с vmstat, установявам, че почти не се използва суап, т.е. употребата на паметта е значително подобрена въпреки по-голямото по обем ядро.
[Отговори на този коментар]
Оптимизации
От: Павел Илиев <pid< at >gbg< dot >bg>
На: 19-09-2002@16:39 GMT+2
Оценка: 1/НеутраленПравил съм някои засичания с -funroll-loops и -funroll-all-loops като това което установих е че при по-слаби pc-та има някакво ускоряване , макар и неголямо, докато при бързи машини (напр. Athlon XP 1800+, 512 DDR/333 MHz, с gcc 3.2) компилацията на 1.6 MB kernel image става за 7 мин + 5 MB модули за 4 мин, както обикновено и няма особен ефект, като се има в предвид че съм правил съвсем акуратни измервания.
[Отговори на този коментар]
екстра супер!!! не мога да повярвам :)
От: mrvoland <voland__at__eda __точка__ bg>
На: 19-09-2002@16:56 GMT+2
Оценка: 1/Неутралензначи сложих само опцията в 2.4.19 kernel-a
-funroll-loops
забележително ми работи PC-то :) като се има в предвид че съм пуснал seti@home преди това ми заемаше 97% от паметта а сега с KDE и seti@home заема само 35 (с 256ram съм) браво :)!!!
[Отговори на този коментар]
спокойно :)
От: Петър
На: 19-09-2002@22:36 GMT+2
Оценка: 1/НеутраленБързината на мандрейк е много далече от бързината на слак.Имах мандрейк когато бях със 700 мхц целерон,после смених процесора с 1200 мхц целерон,и нямаше никаква промяна в бързината.Като сложих слак се оказа че направо лети в сравнение с мандрейка.И не съм правил никакви оптимизации за бързина.Та затова не се притеснявайте,мандрейк е порядъчно бавен :)))
Пробвал съм да сложа ядро компилирано на слак във мандрейк и забелязах че докато в слак летеше,в мандрейк се влачеше.И мисля че в мандрейк го забавят изкуствено с настройки в sysctl,и начина на компилиране на ядрото няма нищо общо с бързината.
[Отговори на този коментар]
Не става дума за това
От: Никола Антонов <linux__at__logos< dot >goto< dot >bg>
На: 20-09-2002@4:38 GMT+2
Оценка: 1/НеутраленНе става дума за бързината на Mandrake, а за бързината на ядрото с пачовете, които Mandrake бяха сложили, някои от тях са заимствани от проекта cipherfunk, други от WOLF, и които станаха след това официална част от ядрото 2.4.19. Така че, тук не става дума за сравнение на дистрибуции, за ядра (или по-точно за IDE производителност със стари чипсети от типа BX). Пакетите на Mandrake са едни от най-бавните и ресурсоемките, това всеки го знае и никой не спори. Причините за това се знаят: освен множеството пачове, които слагат и втежняват кода, всички пакети са компилирани с бъгавия gcc 2.96. Това внася допълнителна тромавост и нестабилонст.
Достойнството на Slackware е, че в него пакетите са компилирани по подразбиране от оригиналния си сорс, вкл. и ядрото, без да са добавяни разни съмнителни пачове. Това го прави много стандартна дистрибуция, еталон за това ка изглежда оригиналният Линукс.
[Отговори на този коментар]
хакът по ядрото - влияние на предпочитания
От: FreeJak
На: 20-09-2002@5:58 GMT+2
Оценка: 1/НеутраленОк, Никола, разбрах те!
Аз обаче си оставам зад моята теза - донякъде ти ме амбицира да създам такова ядро, а от друга страна реших да се разнообразя малко - вече не се задоволявам само с инсталиране.
Компилирам с възможно най-малко модули, понеже съм привърженик на *BSD - работил съм с Free и Open, обаче не мога да ги подържам поради калпав хардуер на тестовата ми система. Затова ги оставям на заден план, докато не се опарича.
От тях свикнах да работя без модули.
Що се отнася за по-мощните машини - всичко е въпрос на опити,преценка и експеримент.Нека някой ако има по-бърза машина, да компилира ядрото както иска и добави CFLAGS_KERNEL = -funroll-loops -O2, след което да пробва да й извади душата.
Хитрото на -funroll-loops e, че спестява изчислението на всички изчислими повтарящи сe цикли, като ги изчислява при компилиране.
-funroll-all-loops - изчислява всички цикли,
без значение дали са изчислени или не.
-02 включва всички оптимизационни опити, без -funroll-*. За да може да се ползва -03, ще трябва да се пипне по-дълбоко - по кода и Makefile-s. Това го оставям за по-нататък.
Никой не може да ме убеди, че хакерите/сисадмините не слагат нещо от себе си в своя Юникс, за да работи по-добре.
Това е само началото.
Живот и здраве, ще се захвана по-сериозно със
С, С#, asm.
Сега PERL до дупки, че се задава comp.mil.serv
[Отговори на този коментар]
glas
От: Beliq
На: 21-09-2002@12:00 GMT+2
Оценка: 1/НеутраленNe zabravqiite da glasuvate. nali ima i takava opciq. POne az glasuvah i to v polojitelna nasoka!
[Отговори на този коментар]
Nvidia
От: milen scouta <milenscouta< at >yahoo__dot__com>
На: 14-10-2002@11:55 GMT+2
Оценка: 1/НеутраленLINUX MANIQ
az polzvam karta Nvidia M64 32MB i polzvam driveri NVIDIA 1.0-3123 i moga da vi zaqva momcheta che sichko si raboti perfektno i nqma problemi s tqh prosto sichko e vapros na nastroiki i malko testova naistina zaspiva mashinata ama tova e pri polojenie che ne si setnal pravilno XF86Configa si taka che nastroivai i oshte neshto na toq forum s mnogo stari i iztarkani neshta se zaribqvate be momcheta zaribete s neshto po qko horata to koito si polzva linux otdavna si gi e izchakalil tiq neshta i po qko zaribqvki ima
az sam linux fen i chestno da vi kaja pishete neshto po zarebitelno na saita
SE PAK TOVA E LINUX ne e WIN MUIN ILI NQKOQ SI TAM DRUGA BOZA
DANO ZAREBITE POVECHE USERI da JIVEE LINUX ieeeee zdravo neshto e
[Отговори на този коментар]
Hubavo, ama...
От: pc_storm
На: 25-10-2002@19:54 GMT+2
Оценка: 1/НеутраленDali tozi nomer 6te ima efekt na RH 8.1 , kojto e izcqlo na gcc 3?
[Отговори на този коментар]
празен суоп?!?
От: manupcho
На: 18-11-2002@11:20 GMT+2
Оценка: 1/НеутраленТова че суоп-а не се използва, истински ме изненадва, по простата причина, че линукс обикновено се старае да няма празен рам. Тоест, ако има място винаги нещо се кешира. Ако това място е необходимо за програма, то чак тогава се освобождава за съответната програма (тоест, пак не остава в крайна сметка свободно). Поне така съм чел...
[Отговори на този коментар]
Drugi optimizatzii
От: Mr.700 <mr700< at >abv __точка__ bg>
На: 26-02-2003@9:36 GMT+2
Оценка: 1/НеутраленProbwah i az towa onova... -funroll-loops i
-frerun-loop-opt ne prechi i ne break-wa
nishto (pone za sega), no ostanalite
(-frename-registers -foptimize-siblin
g-calls -frerun-loop-opt
-foptimize-register-move) pretzakwat neshto
i 2.4.20-kata zabiwa na 12-tina chasa pri
mene.
Shte e interesno ako se hwanem dosta hora
da poeksperimentirame na temata i da widim
kakwo oshte moje da se izstiska ot GCC-to
(az sym s RH8.0 GCC 3.2 tuk). Ako ima oshte
fenowe na temata trqbwa da izmislim kak da
prawim izmerwaneto i testowete :)))
[Отговори на този коментар]
RE: Drugi optimizatzii
От: Никола Антонов <linux< at >logos__dot__goto__dot__bg>
На: 26-02-2003@9:47 GMT+2
Оценка: 1/НеутраленПри мен 2.4.20 също се държи много зле, дори без никакви оптимизации. След 1-2 денонощия работа, включваща компилация на софтуер и гледане на филми, се крашва kswapd и ми умира виртуалната памет. Средно веднъж на денонощие ми се налага принудителен рестарт. Понякога конзолата ме засипва с купчина дъмп-съобщения. Затова ще се върна към 2.4.19, при който машината ми работеше базотказно за неопределени периоди от време и никога не ми се е налагало да прибягвам до рестарт. Нещо не съм доволен от последната версия на ядрото.
Редактиран на: 26-02-2003@9:47
[Отговори на този коментар]
Нестабилно?
От: nikolavp <nikolavp (a) abv__dot__bg>
На: 6-01-2007@22:23 GMT+2
Оценка: 1/НеутраленИскам да попитам до каква степен тази оптимизация може да се счита за нестабилна, защото аз използвам Gentoo и където и да попитах по форумите или Irc каналите всеки ми казва че най-голямата глезотийка, коята имам право да си позволя е вместо O2 оптимизаця да сложа Os, която за незнаещите се използва за смаваляване на размера на приложението повече информация: http://gcc.gnu.org/onlinedocs/gcc-4.1.1... предварително за отговорите, които се надявам да получа :)
[Отговори на този коментар]
слакуеар
От: IsmaiL
На: 28-10-2005@19:33 GMT+2
Оценка: 1/Неутралента значи сега сьм с слак 10.1 кернел 2.4.29 пробвах това и какво се указа.. от 200 200+ мб при старт на линукса + кде-то сега използваемата рам се свежда до 100-150 мб
поздравления за добрата идея
[Отговори на този коментар]