emerge - filozoficky problem
Ked kompilujem X server a pritom ho vyuzivam... Ako je to vlastne mozne? Skompiluje sa inde a po rebootovani sa prepise?
Pre pridávanie komentárov sa musíte prihlásiť.
O Linuxe
Portál
Odporúčame
Podporte nás
Ak sa vám táto stránka páči, môžete nás podporiť tak, že si na vaše stránky umiestnite tento banner.
Náš Twitter tag je #LinuxOSsk
problem zvykne nastat ked ides spustit program ktory vyzaduje kniznice co niesu v pameti. vtedy si natiahne ich nove verzie a moze ti to zletiet ... no a preto sa systemove zasahy maju robit v jednouzivatelskom mode bez grafiky, ved to ze je to mozne neznamena ze je to garantovane :)
Nastastie mi portage zarucuje, ze sa vzdy skompiluju najskor zavislosti a potom az dany balik. Takze kniznice sa opatovne nacitaju tie nove. Problem nastava len v pripade, ze dana kniznica je v pamati vyuzivana este nejakym inym procesom. Spravne som to pochopil?
uvedene priklady som si vymyslel ale z historie si pametam ze to nastavalo, len uz neviem kedy. upgrade systemu robim zasadne v textovom mode a obcas koli tomu aj restartnem. pravdepodobnost ze sa to zrube je mala, ved inac by nerobili graficky instalator gentoo, ale je vecsia ako nula. presnejsie medzi 0 a 1 (teda 0% a 100% mimo krajnych hodnot)
ps.: a navyse som pri pracovani s prikladom nepouzil ldd takze sa o mna neopieraj, ale ked sa ti zrube grafika, tak budes vediet ktore klavesy stlacit a kolko pockat na korektny restart. samozrejme ze po reboote pozri emerge.log
Nemozem najst na webe technicke informacie o alokovani kniznic v pamati. Nepoznas nejaky dobry link?
kedze kod kniznice sa kopiruje do pamati, tak v pamati musim mat prakticky niekolko stoviek megabajtov tych kniznic pritomnych (ak nie vo fyzickej pamati, tak aspon swapovane)? (teda trosku neefektivne zaobchadzanie s virtualnym pam. priestorom oproti Windows z tohoto pohladu)
v kazdom pripade je vacsina kniznic vzdy v pamati, pretoze sa pouzivaju. a neviem kde si prisiel k stovkam MB kniznic, navyse podla teba zbytocne zaberajucich pamat :-/
BTW virtualny pamatovy priestor do toho neplet, ten nema s realnym vyuzitim nic spolocne (takto si moze kazda aplikacia vdaka linuxovemu optimictickemu mallocu alokovat aj viac pamate nez je prave dostupnej, ale to uz su nepodstatne detaily)
a este by ma zaujimalo, ako si prisiel na to, ze windows ma lepsi memory management :) win a ich DLL mozu dopadnut aj tak, ze mas viac kopii DLL v pamati :)
tak ked sa nezamykaju a zaroven neswapuju, tak musia byt vo fyzickej pamati
"a neviem kde si prisiel k stovkam MB kniznic"
Uprimne povedane, som to napisal naschval, aby som poburil verejnost a dostal odpoved na otazku (inak by som dostal odpoved: co tam par nejakych MB- co samozrejme nie je odpovedou na moju otazku)
"BTW virtualny pamatovy priestor do toho neplet"
ved o tom to je, ako zefektivnit, aby virtualny pamatovy priestor bol realne co najlepsie vyuzity.
"a este by ma zaujimalo, ako si prisiel na to, ze windows ma lepsi memory management :) "
Nespominam si, ze som taketo nieco tvrdil. Ale urcite som tvrdil, ze z pohladu, ze Windows namapuje DLL subor do adresneho priestoru procesora tak, ze fyzicky ten DLL subor sa nachadza na disku presne na tom istom mieste (pamatovo mapovany subor vo Win32) oproti linuxu- kde sa tento subor namapuje skopirovanim (to znamena, ze zostane bud vo fyzickej pamati alebo v swape)- vychadza memory management vo vyuzivani celkoveho pamatoveho priestoru lepsie pre Windows.
tak ked sa nezamykaju a zaroven neswapuju, tak musia byt vo fyzickej pamati
"a neviem kde si prisiel k stovkam MB kniznic"
Uprimne povedane, som to napisal naschval, aby som poburil verejnost a dostal odpoved na otazku (inak by som dostal odpoved: co tam par nejakych MB- co samozrejme nie je odpovedou na moju otazku)
"BTW virtualny pamatovy priestor do toho neplet"
ved o tom to je, ako zefektivnit, aby virtualny pamatovy priestor bol realne co najlepsie vyuzity.
"a este by ma zaujimalo, ako si prisiel na to, ze windows ma lepsi memory management :) "
Nespominam si, ze som taketo nieco tvrdil. Ale urcite som tvrdil, ze z pohladu, ze Windows namapuje DLL subor do adresneho priestoru procesora tak, ze fyzicky ten DLL subor sa nachadza na disku presne na tom istom mieste (pamatovo mapovany subor vo Win32) oproti linuxu- kde sa tento subor namapuje skopirovanim (to znamena, ze zostane bud vo fyzickej pamati alebo v swape)- vychadza memory management vo vyuzivani celkoveho pamatoveho priestoru lepsie pre Windows.
nemusia. proste sa ti to moze po nahradeni zdrbat. ale sanca nie je velka. ja som bez problemov nahradil kadeco... (aj glibc, ale ta si dava za ciel binarnu kompatibilitu)
>>"BTW virtualny pamatovy priestor do toho neplet"
> ved o tom to je, ako zefektivnit, aby virtualny pamatovy priestor bol realne co najlepsie vyuzity.
nie. virtualny pamatovy priestor ma kazda aplikacia vlastny! to jest 4GB (teoreticky, na 32bit masinach bez zapnuteho PAE sa defaultne v linuxe rozdeluje tusim 1GB kernel+3GB app)
> ze z pohladu, ze Windows namapuje DLL subor do adresneho priestoru procesora tak, ze fyzicky ten DLL subor sa nachadza na disku
to ale nie je pravda :) praveze ELF shared libraries maju Position Independent Code a DLL nie. na windows sa preto moze stat, ze musi loadovat aj viackrat to iste DLL (menej pravdepodobne) alebo relokovat DLL na inu adresu, pretoze na jej zakompilovanej adrese uz nejaka ina kniznica je...
> vychadza memory management vo vyuzivani celkoveho pamatoveho priestoru lepsie pre Windows.
to si vazne nemyslim :) aj keby som odhliadol od svateho fork() (man 2 fork :)) tak by IMHO dopadol lepsie. dokazat nemam ako... a mozes upresnit co je "celkovy pamatovy priestor"? ak to suvisi s virtualnymi priestormi, tak je ti uz snad jasne, ze to je ihla v kopke sena. ak s fyzickou, tak ver tomu,, ze fork a shared libraries s PIC ti setria pamat...
Vychadzam z predpokladov, ze spustany kod sa musi nachadzat vo virtualnom adresnom priestore. Bolo povedane, ze subor sa nezamyka => jedina moznost je, ze OS si kod precita do pamate (spolocneho adresneho priestoru, ktory je prerozdelelny do virtualnych adresnych priestorov procesov). A kedze sa neswapuju, tak sa musia nachadzat v RAMke...
Tieto predpoklady, ktore mi boli podsunute, sa vsak nezdaju objetivnymi:
"Linux uses demand paging to load executable images into a processes virtual memory. Whenever a command is executed, the file containing it is opened and its contents are mapped into the processes virtual memory. This is done by modifying the data structures describing this processes memory map and is known as memory mapping. However, only the first part of the image is actually brought into physical memory. The rest of the image is left on disk. As the image executes, it generates page faults and Linux uses the processes memory map in order to determine which parts of the image to bring into memory for execution." (Linux Memory Management, z webu)...
____
"ved o tom to je, ako zefektivnit, aby virtualny pamatovy priestor bol realne co najlepsie vyuzity"
Zle som sa vyjadril. Spravne malo byt: Ved o tom to je, ako zefektivnit, aby celkovy pamatovy priestor dostupny procesory bol realne co najlepsie vyuzity...
____
> to ale nie je pravda :) praveze ELF shared libraries maju Position Independent Code a DLL nie.
To nic nemeni na fakte, ze DLL je namapovany do virtualneho priestoru procesu a pritom fyzicky je na HDD na tom jednom jedinom mieste...
____
to si vazne nemyslim :) ze "vychadza memory management vo vyuzivani celkoveho pamatoveho priestoru lepsie pre Windows."... fork()...
Diskusia nebola o tom, ci shared libraries su pamatovo efektivnejsie ako static a ani ktory MM je lepsi. Len som poukazal, ze ak by to bolo tak, ako tu bolo tvrdene, ze sa precitana oblast fyzicky na disku leziacich udajov kniznice nie len namapuje do pamate, ale aj skopiruje, tak potom mam data pritomne 2* (u Win len raz): na disku fyzicky a potom aj v pamati...
a v linuxe je to inak? ta ista shared library sa nemoze len tak nachadzat v pamati 2x
> Len som poukazal, ze ak by to bolo tak, ako tu bolo tvrdene, ze sa precitana oblast fyzicky na disku leziacich udajov kniznice nie len namapuje do pamate, ale aj skopiruje, tak potom mam data pritomne 2* (u Win len raz): na disku fyzicky a potom aj v pamati...
a tym si mi potvrdil domnienku. kod, ktory sa spusta musi byt v RAM!
____
a tym si mi potvrdil domnienku. kod, ktory sa spusta musi byt v RAM!
Ale to neznamena, ze vsetok kod (to znamena, ze vsetok kod v kniznici). A o tom to bolo.
nechapem co tu este riesis? vies ake by bolo zdrzanie, keby cakal na demand paging kazdej stranky kniznice? rozhodovanie o potrebe loadovania nechaj na jadre a neries, o to viac ked celkom nechapes tym mechanizmom...
Veciam rozumiem (i ked som uz vysiel z cviku a nie vzdy som pouzival spravne nazvy)- tak napriklad swapovana stranka bola u teba stranka na disku a u mna stranka ulozena konkretne vo swapovacom oddieli.
Inak aby si to nebral utocne- vazim si ta a sledujem tvoje reakcie v diskusiach a som rad, ze som si s tebou mohol vymenit nazory. ;-)
u mna je stranka akakolvek stranka z pamate (stavebny kamen memory managementu a strankovania) nech sa nachadza kdekolvek
> Inak aby si to nebral utocne
neberiem
Tak este raz- ako je teda mozne prepisat subor s kniznicou, ktora sa pouziva, ked "The rest of the image is left on disk"?
Fyzicky tento subor nie je mozne prepisat. V praxi sa prida dalsi subor so zmenenou verziou a update-uje sa link kniznice na poslednu verziu. Takze novo spustane procesy loaduju kniznicu s novsou verziou.
otvoreny subor sa fyzicky z disku nezmaze a preto je mozne ho "odswapovat" (realne je ulozeny iba v tom jednom subore) a ked sa "prepise" (vytvori sa dalsi subor s tym istym menom), tak spustane aplikacie pouzivaju tuto verziu.
Vychadzal som z mylnej informacie, ktoru mi tu vsak nikto nevyvratil. Zistil som vsak jej nepravdivost sam. Otvoreny subor teda nie je mozne fyzicky na disku zmenit. Princip je rovnaky ako u Windows. Rozny je len fakt, ze v linuxe sa kniznica linkuje cez "linku vo filesysteme" a ta moze ukazovat na inu- najnovsiu verziu kniznice (vo Windowse to tak nefunguje). Dalsi rozdiel je v relativnych adresach pouziti pri volaniach funkcii z kniznic (vo Windowse sa musi pouzivat prelinkovavanie a hladanie miesta pre namapovanie DLL).
nemam prehlad o vsetkych moznych situaciach pri roznych rezimoch otvorenia, ale je to tak, ze ked mas otvoreny file descriptor, fyzicky sa z disku nemaze. mozes si to skusit otvorenim suboru (napriklad nejaku mp3 prehrat), zmazat a subor si mozes stale najst v /proc/$PID/fd/
> Princip je rovnaky ako u Windows.
princip nie je vobec rovnaky, tam su na suboroch zamky a nic s tym nezmozes.
> Rozny je len fakt, ze v linuxe sa kniznica linkuje cez "linku vo filesysteme" a ta moze ukazovat na inu- najnovsiu verziu kniznice (vo Windowse to tak nefunguje)
so symlinkami to suvisi len v tom, ze sa nova aplikacia automaticky dostane k najnovsej verzii prave cez neho, samotny subor na ktory odkazuje sa moze "prepisat" aj keby to nebolo cez symlink. navyse neviem ci by win na zmenu prisiel, pretoze nema ako vediet verziu...
Myslim12, ze tento tvoj prispevok vystihol vsetko.