Dotaz: Distcc - alternativa alebo jednoduche nastavenie

[normalny_student]

Zdravim,

chcel by som, aby mi pri kompilacii pomahali skolske PC. Ma to ale problem - tie PC obsahuju 32bit "smejdarnu" - OS a aj vsetky nastroje, pricom ja chcem kompilovat programy pre architekturu x86-64.

Napadlo ma skompilovat cross toolchain pre skolske PC, ale mam problem, ze na kompilaciu mi nestaci kvota a roota nemam.

Teda riesenim by bolo nainstalovat si 32 bit cross toolchain pre moj domaci 64 bit system a pomocou neho skompilovat cross toolchain pre skolske PC.

Je toto najjednoduchsie riesenie? Ak nie, tak ako to spravit jednoduchsie? Distcc nie je podmienka, je to len aktualne nastavenie.

Odpovědi

[ewew]

Myslíš, že bez roota niečo skompiluješ ?

[normalny_student]

Ja si myslim, ze kludne. Ak sa pocita len "rucna kompilacia" (=nie emerge), tak kompilujem len pod neprivilegovanym uzivatelom a zatial vsetko bezi. Na "dojem" roota mi staci fakeroot.

[ewew]

Čo konktretne potrebuješ skompilovať ?

[normalny_student]

Chcel by som minimalne niekolkokrat kernel (bisect) a ak to pojde dobre, tak aj cely system (Gentoo).

[ewew]

Tvoj pc na to nestačí ? Aké máš komponenty vo svojom PC ? Myslíš, že školské PC budu na to lepšie.

[normalny_student]

Mozno by stacil, ale trvalo by to dlho a neskusil by som si pri tom nic nove. PC v skole maju len podla poctu jadier 2 az 4x taky vykon ako moj PC a to este neuvazujem, ze je tam novsia architektura CPU pri vyssej frekvencii.

[ewew]

Naštuduj si ccache. Možno to pomôže skrátiť čas kompilácie.

[normalny_student]

To subjektivne nepomohlo - skompiloval som kernel 2 krat (raz po bisecte) a pravdepodobne to cacheovanie nie je stavane na taketo upravy alebo mam mozno nieco zle  nastavene (nastavovanie nebolo skoro nijake, len par env. variables a instalacia ccache).

$ ccache -s
cache directory                     /home/user/.ccache
cache hit (direct)                     2
cache hit (preprocessed)              14
cache miss                         27353
called for link                       63
called for preprocessing            5035
unsupported source language          184
no input file                       5129
files in cache                     56328
cache size                           4.3 Gbytes
max cache size                       5.0 Gbytes

[Michal Kubeček]

Pokud to bylo v prvním kroku, tak tam se to dá celkem očekávat. V pozdějších krocích už by to ale mělo být výrazně lepší.

[ewew]

Mne sa osvedčilo pred ďalšou kompiláciou vyčistiť adresár s už skompilovanými objektmi. Takto to aspoň funguje pri kompilácii kernelu.

[pavlix]

distcc umí přehodit část práce na kompilaci (ve striktním smyslu) na jiný stroj. Ale moc to neškáluje. Při nějakých dvou nebo třech strojích podle mě stejně zjistíš, že tě kompilace (převádění zdrojáků na objektové soubory) nezdržuje zdaleka tak, jako ostatní akce.

[normalny_student]

A ako teda urychlit tie dalsie akcie? Inak aj zmensenie trvania na polovicu pri desiatkach PC by mi aspon trochu pomohlo - uz by to nebolo planovanych 36 hodin, ale 18 hodin, co je pre mna velky rozdiel.

[pavlix]

A ako teda urychlit tie dalsie akcie?

Pořídit rychlejší počítač, ať už osobní nebo buildserver. Ale rychlejší především v oblasti storage.

nak aj zmensenie trvania na polovicu pri desiatkach PC by mi aspon trochu pomohl

Od určitého počtu při sebelepší konfiguraci prostě nebudeš mít, co na ty počítače odložit. Nedá se té kompilaci úplně vyhnout a nechat to na nějakém distributorovi?

[normalny_student]

Pořídit rychlejší počítač, ať už osobní nebo buildserver. Ale rychlejší především v oblasti storage.

Tak na to asi nemam, kedze nejde o nic komercne. Teraz ma napadlo, ze by to mozno islo buildit na ramdisku, ale na to asi nemam vela RAM (cely build mi tusim nesiel pri menej ako cca 10GB disku)

Od určitého počtu při sebelepší konfiguraci prostě nebudeš mít, co na ty počítače odložit.

S neidealnym skalovanim pocitam; ide mi aj len o nejake zrychlenie.

Nedá se té kompilaci úplně vyhnout a nechat to na nějakém distributorovi?

To je dobry napad, diky moc. Davnejsie som sa k openSUSE build service nedostal kvoli chybe na stranke, teraz to uz tusim funguje, tak to skusim.

[Michal Kubeček]

Tak na to asi nemam, kedze nejde o nic komercne.

120GB SSD dnes pořídíte kolem 2000 Kč s DPH, na buildroot z něj bude stačit tak 16 GB, takže ještě zbyde dost na kořenový filesystém a nějaký pracovní. Rozdíl v rychlosti buildu je dost zásadní.

Teraz ma napadlo, ze by to mozno islo buildit na ramdisku, ale na to asi nemam vela RAM (cely build mi tusim nesiel pri menej ako cca 10GB disku)

Pokud nepotřebujete debuginfo (což pro bisect obvykle nepotřebujete), dá se jeho vypnutím náročnost výrazně snížit. Např. na build (x86_64) jádra SLES 11 SP2 nebo OpenSuSE 12.2 mi bez debuginfa pro buildroot stačí 4GB tmpfs, zatímco s ním bych potřeba asi 9-10 GB. Jako bonus bude build i o dost rychlejší. (Hodnoty jsou pro kompletní build distribučního balíčku pomocí "osc build", pro build samotného jádra a modulů přímo ze zdrojáků to bude o něco méně.)

[pavlix]

To je dobry napad, diky moc. Davnejsie som sa k openSUSE build service nedostal kvoli chybe na stranke, teraz to uz tusim funguje, tak to skusim.

Akorát hodně těch veřejných build služeb je pomalejších než lokální build.

[radeczek]

A s jakým připojením budeš napojen k těm mašinám? Jestli LAN 100Mbit, tak je to ok, ale jestli půjdeš něčím slabším(nebudeš u nich, ale půjdeš přes net s nějakým slabším spojením), tak si stejně moc nepomůžeš.

Jak dlouho ti trvá zkompilovat ten kernel? Má to distcc vůbec smysl? Vždyť když neděláš nějaké zásadní změny, tak se kompiluje jen část jádra.

[normalny_student]

Robim git bisect, takze su to zasadne zmeny skoro vsade, kde sa udiali medzi Linux 2.2. a Linux 2.3. Kompilacia jadra trva s ccache cca 3 hodiny (je to vanilla, ale bug sa neprejavuje pri mojom mini configu - prejavuje sa pri distribucnom configu, takze treba kompilovat vsetko alebo nejak skusit "bisect" na kernel config).

Stve mna, ze pri pisanych 12 krokoch je to cca 36 hodin a ak niekedy nezaregujem hned a PC vypinam vzdy, ak je mimo mojho dohladu (spim, nie som doma), tak to budem riesit este minimalne tyzden.

Pripojenie snad nepotrebujem riesit - ak to pri testovani nejak bude fungovat, tak to dam svoj PC do skoly na LAN, kde to v optimalnom pripade pojde 1Gbit.

[normalny_student]

Edit: nie 2.2, a 2.3 ale 3.2 a 3.3

[Peter Golis]

36 hodín kompilácie jadra 3.3 ? To sa mi nejak nezdá. Použitý CPU má slabšie CPU ako bežný telefón ?

[Michal Kubeček]

Ne, tazatel psal, že jedna kompilace trvá tři hodiny. 36 je odhadovaná doba na (předpokládaných) dvanáct kroků bisectu.

[Peter Golis]

Ajtak, kompilácia jadra za 3 hodiny. Toľko to trvá na mojom G4 1.2 GHz bez ccache. Ani nebudem hovoriť ako starý je to stroj. Neviem, či sa chalanovi oplatí tomu živiť elektrinu. Predsa len, x86/64 tak nízkeho výkonu mali horšiu spotrebu ako ten môj črep.

[normalny_student]

Dakujem, uz som to vyriesil, aj ked nakoniec pomohol upraveny modprobe a trocha intuicie. Tie 3 hodiny boli kvoli modulom (distribucny kernel), lebo v osekanom kerneli sa mi bug neprejavoval.

Takze keby niekomu nefungovalo pripojenie Androidu k PC, tak treba v kernel configu vypnut CONFIG_USB_OTG, ktore v poslednom case zacali zapinat packageri. Bug je este o nieco hlbsie, ale to tu uz nebudem rozoberat.

[Michal Kubeček]

Nezapomínejte na to, že "kopilace jádra" je hodně široký pojem. Když si budete buildit jádro "na míru" (tj. je vám jedno, že až vyměníte síťovou kartu, budete muset buildit nové), bude to podstatně rychlejší než když půjde o ekvivalent distribučního jádra (což je případ tazatele). Pokud se navíc vytvářejí kompletní balíčky, docela dost času spolkne samotný rpmbuild (který většinu času navíc běží jen na jednom procesoru). Vezmu-li v úvahu, že kompletní balíček aktuální distribuce na mém stroji (4x2.4 GHz Phenom z první generace, 6 GB paměti, buildroot na SSD) trvá asi 70 minut, tak mi pro jednojádrový procesor a klasický disk ty tři hodiny nepřipadají nijak přehnané (i kdyby nedělal RPM).