Linux 2.6.35.2, 2.6.34.4, 2.6.32.19, 2.6.27.51 (diskuse)

[d.c.]

A věřili byste, že pamatuji dobu, kdy měl Linux jen 3 větve? Vývojovou (2.5.x), stabilní (2.4.x) a starou stabilní (2.2.x). Kde kdo tenkrát dával vývoj kernelu za vzor a používal obdobné či stejné číslování. Stroje tehdy dosahovaly uptime i přes 1000 dnů a přesto docházelo k vývoji mnoha nových funkcí a vlastností i při mnohem menším počtu programátorů.

[Piškot]

Ale běžel na polovině hardwaru :(

[thingie]

Věřili, ale vracet bychom se k tomu nechtěli. V takovém případě by tu teď byla nějaká verze 2.8.cosi vývojově někde tak kolem skutečného 2.6.20, a všichni bychom stejně používali 2.9 větev, protože by nic jiného nešlo.

[pc2005]

Tak dneska je imho jediná a do určité hloubky historie se dávaj bezpečnostní patche. Aspoň se netříští síly.

Mě fascinuje (spíš negativně), jak roste velikost jádra. Pamatuju si, jak jsem před pár lety hrál s Monkey linuxem a když jsem měnil jádro z 2.2 na 2.4, tak jsem musel updatovat zavaděč, protože ten neuměl bootovat >1MB obrazy. No a když jsem si asi před 14 dny kompiloval 2.6, tak jsem byl zdešen, že má přes 3.5MB (což je skoro tolik, co má původní distribuční s maximem ovladačů). A to bylo 2.4 i 2.6 optimalizovaný na jeden komp.

[psonek]

No on ma kernel takovou sikovnou vec, ktere se rika config. Muzes si tam zakompilovat jenom to co potrebujes. Nevim jak X86, ale na ARMu ma kernel co nabootuje ~1MB.

[pc2005]

Vždyť jo:

A to bylo 2.4 i 2.6 optimalizovaný na jeden komp.

To, že jsem to porovnával s 4MB huge od slacku 12.1 bylo fakt jen to porovnání. Přímo v jádře mám akorát PATA, asi tři framebuffery a pár věcí jako třeba usb mass storage. Většina je jako modul nebo není. Nevím proč je tak velký (nebo teda doufám, že to není tím, čím si myslím ). Jádro na ARMu 2.6.35 (i věci jako framebuffer) má asi 2MB (stroj mám vedle sebe).

[Marek Niklíček]

Arch Linux x86_64 stock kernel (2.6.35.1) má u mňa 2.1M a myslím, že štandardne sa používa kompresný algoritmus LZMA. S Gzip, alebo LZO by veľkosť mohla byť väčšia, čo by odpovedalo rozdielnym veľkostiam v ostatných distribúciach.

[pc2005]

Hmmm mám LZO. Vlastně ještě by se mohlo pár stovek kB sehnat tím, že mám nastavenej velkej log. buffer (512kB). Ale zase třeba komplet IPv6 mám jako modul . Všechny kromě jedný síťovky (má flash na sobě) taky. Hmm a asi polovinu debugovacích nástrojů.

Co všechno je v tvém jádru?

[Marek Niklíček]

Väčšina sú moduly. Celý konfiguračný súbor jadra 2.6.35.2 v Arch Linuxu je tu: config.x86_64. Okrem toho 2.1M kernelu je potrebný ešte initramfs, kde sú vložené moduly potrebné na nabootovanie systém. Ten obraz je u mňa veľký s Gzip 2.4M a s LZMA 1.9M. Adresár so všetkými modulmi uložený na HDD má 105M.

[pc2005]

Příloha:

• config (76148 bytů)

Tak to nechápu, dal jsem si tvůj a můj config prohnat grepem na =y volby a tvůj je větší (tedy má víc voleb) a to můj má i věci jako optimize for size :-O.

-rw-r--r-- 1 root root 3728576 2010-08-05 20:34 vmlinuz-2.6.35-nitro

[Roman Horník]

Pokud vím, standardní je GZIP (alespoň u Debiana).

[Marek Niklíček]

Arch má u jadra štandardne LZMA (možnosti LZO, Gzip, Bzip2, LZMA) a u initramfs image Gzip (možnosti Gzip, Bzip2, LZMA).

[Roman Horník]

Díky za info, taky radši volím LZMA. Vůbec ale nevím, na co tam je LZO. Komprimuje docela slabě (i když na TAR ani na CPIO nemá :D ), ani nejrychlejší není.

[Marek Niklíček]

LZO nie je najrýchlejší? Veď práve jeho výhodou je real-time kompresia. Rôzne benchmarky kompresných algoritmov sa dajú nájsť na Internete a minimálne z týchto pár je LZO výrazne (naj)rýchleší. Taktiež som robil sám pre seba testy a LZO má mierne horší kompresný pomer než Gzip, ale rýchlostne ho drví (aspoň 2x vyššia rýchlosť s LZO oproti deflate). Preto netrpezlivo čakám na podporu LZO kompresie pre BTRFS namiesto zlib_deflate. Určitý čas som na netbooku používal compache, ktorý tiež používal LZO a kompresný pomer bol cca 1:4 a dopad na rýchlosť RAM / systému som nezaznamenal.

[Roman Horník]

Nevím, ale při bootu se mi zdálo bejt LZO zhruba stejně rychlý jak LZMA, ale měřil jsem to jen svým 14Hz analogovým procesorem.

[Marek Niklíček]

Síce to možno bude trochu mimo tému, ale spravil som si opakovaný test kompresie a dekompresie LZO, Gzip a LZMA na textovom súbore o veľkosti 2 GiB a prekvapili ma výsledky dekompresie.

Kompresia:
LZO: 7.6 sekúnd; 8.3 MiB
Gzip: 27.8 sekúnd; 2.0 MiB
LZMA: 3 minúty, 56.2 sekúnd; 296 KiB

Dekompresia:
LZO: 6.9 sekúnd
Gzip: 12.5 sekúnd
LZMA: 6.0 sekúnd

Podľa tohto výsledku je algoritmus LZMA v dekompresii o niečo lepší než LZO. Testované na notebooku s procesorom Intel Core i5 430M @2,26 GHz a 6 GiB RAM. Možno by výsledok dopadol inak na slabšom počítači, napr. na netbooku s Intel Atom.

[Roman Horník]

Pak jsem si vybral správně. Mimochodem- je to opravdu texťák, nebo je to vygenerováno z /dev/zero?

Schválně zkusím zdroják zvratků JUDr. PhDr. Mgr. et Mgr. Henryka Laholy :D

[Marek Niklíček]

Textový súbor, ale je v ňom veľa opakujúcich sa častí. Fakt ma prekvapila rýchlosť dekompresie LZMA, pretože tú som nikdy nemeral. Predpokladal som, že bude najpomalšia. A ešte mimochodom, celý ten test bol robený v RAM.

[Roman Horník]

Hned mi bylo divný, že jsou ty archivy tak malý :)

[Marek Niklíček]

Iný výsledok som dostal, keď som skúšal LZO a LZMA na adresár so všetkými modulmi (105 MiB). Kompresia s LZMA trvala 1 minútu, 33 sekúnd a s LZO len 1 sekundu (v oboch prípadoch boli súbory prednačítané v cache). Dekompresia s LZMA trvala 3 sekundy a s LZO 2 sekundy. Čo sa týka výslednej veľkosti, tak LZMA archív mal presne 20M a LZO archív presne 40M.

[pc2005]

Hmmm tak to ho asi vyhodím. Jsem myslel, že když je nakonci, tak že bude lepší .

[Marek Niklíček]

Urobil som test a jadro s LZMA je veľké 2.1M a jadro s LZO 2.8M. LZMA má výhodu v kompresnom pomere a LZO zase v rýchlosti (de)kompresie.

[ext3fs]

Slackware-current, linux-2.6.35.2 (podpora BT,PCMCIA,IPv6,netfilter,...)...co slo mam jako moduly a velikost bzImage je 2.1MB.

[čavo]

Příloha:

• config-2.6.34-gentoo-r1 (83581 bytů)

Nechápem, čo tam všetci máte zakompilované. U mňa má 1,7 mega a na nabootovanie nepoužívam ani initrd.img. -rw-r--r-- 1 root root 1770144 2010-07-01 14:58:38 /boot/vmlinuz-2.6.34-gentoo-r1

[pc2005]

Týjo fakt že jo. Zkompiloval jsem .35 podle tvýho configu a vyšlo něco okolo 1.7MB. Zajímavý a přitom mám míň hw podporovanýho než ty. Asi počet voleb v configu není všechno :-/.

Takže podezřelí na žraní místa v jádře jsou asi log buffer, relocatable kernel (konfigurace od nuly, asi to není zas tak dobrý nápad :-/), kdbg a možná framebuffery nvidia a ati.

Každopádně i tak jsou ty jádra dost velký, schválně jsem si rozbalil monkey linux a to jádro (2.0.33) má 300kB .

[Grunt]

Existují (či možná existovali) různé HOW-TOčka jak optimalizovat velikost jádra prolézáním všelijakých binárních bastlů. Používalo se to hlavně tam kde bylo potřeba dostat jádro třeba do 512kB RAM (různé jednočipy usw.). Ale aniž bych vytahoval nějaké linky, tak mě z hlavy napadá třeba:

du -h `find . -name "*.o"` | sort

(v kořenu zdrojáků linuxu samozřejmě) Pak si jen stačí překládat jména souborů na volby a vyhazovat ty co žerou nejvíc. Bohužel to není moc pohodlné. Zdá se, že jednoduchý KConfig pomalu přestává stačit a bude třeba něco sofistikovanějšího.

[pc2005]

Nejhorší je, že jsem viděl i pár zdrojáků s funkcema, který nebyly nikde nepoužitý (nebo jsem je aspoň po usilovném grepování nenašel). Takže pak zabíraly místo. Nebo slučování ovladačů pro různé verze hw. Kde je pak většina řádků nějaké funkce strom podmínek na verzi.

P.S. Tuhle jsem měl nápad nakopírovat všechny zdrojáky v Linuxu do jednoho obrovskýho a ten pak zkompilovat najednou. Docela věřím, že by se významně snížila doba kompilace .

[Grunt]

P.S. Tuhle jsem měl nápad nakopírovat všechny zdrojáky v Linuxu do jednoho obrovskýho a ten pak zkompilovat najednou.

To já též, jen se to netýkalo zdrojáků Linuxu. Možná by to nějaký preprocesor zvládnul (zas by to sežralo paměti jako pes).

[pc2005]

Tak já díkybohu nic většího než jádro nekompiloval (kromě kompilátoru samotnýho, ale ten se snad ani optimalizovat nedá - ve smyslu náročnosti ), ale je jasný, že by to šlo i jinde.

Paměti by to žralo fakt dost, ale zase by se nemuselo gcc pouštět kvůli každýmu .h (+ přenášet hafo parametrů a načítat hafo hlavičkovejch souborů).

[mimi.vx]

k cemu framebufery nvidie a ati, s binarnimi ovladaci jen koliduji a pri pouziti oss ma kms v sobe FB ....

[pc2005]

Mě se nikdy napoprvé nepovedlo vesafb nahodit, vždycky jsem skončil na textový konzoli . Což vzhledem k tomu, že jsem testoval novou vrstvu pro ATA (+přejmenování hda→sda) a zaboha to nejelo. V texťáku se všechno odrolovalo a hnedka se zamrzlo na kernel panicu. Subjektivně jede akcelerovanej framebuffer rychlejc .

To, že to koliduje je fakt, ten atifb nějak blbě nastavuje hodiny, takže v embedded tv kartě pak mám čtverečky . Spíš než vyhodit ovladač by byl lepší nějakej parametr, kterej zakáže probe danýho ovladače (občas prohazuju grafiky na stroji).

[Roman Horník]

-rw-r--r-- 1 root root 1548240 15. srp 17.31 /boot/vmlinuz-2.6.35.2-0 (1.4765MiB)

[Roman Horník]

No a v repu Sida je furt jen 2.6.32, naštěstí mi kompilace kernelu nedělá potíže, takže asi za půl hodinky nabootuju na 2.6.35.2 :)

[Roman Horník]

Hň hň hň

[asfethan]

V experimental je uz 2.6.35 (trunk), prave na tejto verzii ficim

[wylda]

Mohu se zeptat, co znamená to "trunk"? Vanilla to asi nebude, když jsou z toho zase vyřezané binární firmwary pro síťovky apod.

[Roman Horník]

Trunk = kufr :)

Nevím to přesně, ale nejspíš to bude předkompilovanej univerzální kernel se standardní konfigurací (jak píšeš, vysekaný "nevhodný" binárky) pro daný distro.

[Roman Horník]

Po mně to chce kbuild stejný verze, kterej tam ale není. Ale to mi nevadí, kernely si už budu jenom kompilovat, stejně jako třeba GCC.

[asfethan]

Tiez som tak robil kedysi. Ale zpohodlnel som a to duplom vtedy ked sa v repozitaroch zacali objavovat rc verie kernelu.

[Wylda]

Ja bych byl opatrny... Zda se, ze kazda z tech uvadenych stable je najednou NEstable

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

S updatem radeji vyckejte jeste tech 999 dnu ;)

[d.c.]

Což docela pěkně potvrzuje, co jsem psal na začátku. Řeknu to tedy jinak. Pamatuji dobu, kdy měl Linux i stabilní větev jádra. A dovolím si nepapouškovat obvyklé cliché: běhalo to na úctyhodném množství HW.

[Rovano]

Zajímává zkušenost. Já to vidím opačně. Dřív nebyl problém shodit stabilní řadu jádra. Dnes je situace ovela lepší.

[ext3fs]

Ja kdyz jsem zacinal s linuxem (RedHat 5.X) jsem byl nucen stejne pouzivat kvuli hodne novemu HW linux 2.3 misto 2.2. Take na tu dobu vzpominam.

[trekker.dk]

Na úctyhodném množství starého HW. Kdo si koupil nový stroj, dost často měl 2.5 nebo smůlu. Ale to je jedno, hlavně že s 2.4 mohl mít člověk uptime 1000 a jádro plné známých bezpečnostních chyb.

[R]

A mas teraz nejake problemy so stabilitou? Ja som mal akurat s hibernaciou, ale to uz je opravene. Inak nie je problem mat 300+ dni uptime (upgradovat jadro ale s restartom pockat na najblizsi vypadok napajania alebo siete).