emerge - filozoficky problem

Sekcia: Konfigurácia 17.01.2007 | 18:12
Avatar jv openSuSE 11  Používateľ
Ked kompilujem X server a pritom ho vyuzivam... Ako je to vlastne mozne? Skompiluje sa inde a po rebootovani sa prepise?
    • Re: emerge - filozoficky problem 17.01.2007 | 19:18
      WlaSaTy   Návštevník
      normalne, pomocou emerge kompilujes v /var/tmp/portage a prelozene binarky (programy + kniznice) sa nainstaluju bez problemov nakolko sa v unixe nepouziva mechanizmus uzamknutia spustenych programov ako vo winblows. spustene programy aj s kniznicami su uz v pameti pretoze mas nastartovanu grafiku takze to funguje. ak restartnes graficke sedenie, tak mas uz vsetko v pameti nove.

      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 :)
      • Re: emerge - filozoficky problem 17.01.2007 | 19:35
        Avatar jv openSuSE 11  Používateľ
        Super, dik za vysvetlenie...
        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?
        • Re: emerge - filozoficky problem 17.01.2007 | 19:51
          WlaSaTy   Návštevník
          takmer, problem je ked nacitas napriklad program Eye Of Gnome (eog) vyzadujuci kniznicu libpng a ta nie je v pameti. vtedy sa nacita jej nova verzia (ak bola upgradnuta) a ta bude vyzadivat libX11 no a libX11 uz bude novsej verzie. ak vsak bude velmi nove a nekompatibilne zo starou, tak sa to cele zrube.

          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
          • Re: emerge - filozoficky problem 17.01.2007 | 20:11
            Avatar jv openSuSE 11  Používateľ
            Vdaka. Ja som uz viac raz emerge-oval z KDE polku systemu :-)
            Nemozem najst na webe technicke informacie o alokovani kniznic v pamati. Nepoznas nejaky dobry link?
            • Re: emerge - filozoficky problem 17.01.2007 | 21:43
              WlaSaTy   Návštevník
              google, ale musis zadat rozumny retazec na vyhladavanie.
            • Re: emerge - filozoficky problem 17.01.2007 | 21:43
              Avatar Igor Hlina Mac OS ML  Používateľ
              wikipedia
              while (2*2 == 5) { echo "If you're reading this, something is definitely wrong"; }
              • Re: emerge - filozoficky problem 17.01.2007 | 23:25
                Avatar jv openSuSE 11  Používateľ
                Vdaka, avsak problem je, ze sameho ma prekvapilo ako linux pouziva shared libraries- dal som si hladat a nic nove, ale asi preto, ze vlastne to, co som chcel vediet, sa da vysvetlit odpovedou na 1 otazku:
                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)
                • Re: emerge - filozoficky problem 18.01.2007 | 00:06
                  Avatar uid0 Debian  Používateľ
                  nie, objektove subory sa (vychadzajuc z teorie) nezvyknu swapovat, pretoze sa v pripade potreby mozu znova naloadovat. v tomto konkretnom pripade ale neviem co sa udeje, mozno si ten subor kernel zamkne, mozno nie...

                  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 :)
                  Debian. apt-get into it…
                  • Re: emerge - filozoficky problem 18.01.2007 | 12:14
                    Avatar jv openSuSE 11  Používateľ
                    "nie, objektove subory sa (vychadzajuc z teorie) nezvyknu swapovat, pretoze sa v pripade potreby mozu znova naloadovat. v tomto konkretnom pripade..."
                    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.
                  • Re: emerge - filozoficky problem 18.01.2007 | 12:19
                    Avatar jv openSuSE 11  Používateľ
                    "nie, objektove subory sa (vychadzajuc z teorie) nezvyknu swapovat, pretoze sa v pripade potreby mozu znova naloadovat. v tomto konkretnom pripade..."
                    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.
                    • Re: emerge - filozoficky problem 18.01.2007 | 15:26
                      Avatar uid0 Debian  Používateľ
                      > tak ked sa nezamykaju a zaroven neswapuju, tak musia byt vo fyzickej pamati

                      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...
                      Debian. apt-get into it…
                      • Re: emerge - filozoficky problem 18.01.2007 | 15:44
                        Avatar jv openSuSE 11  Používateľ
                        Celkovy pamatovy priestor je priestor procesora, kde moze on a vsetky procesy na nom beziace ukladat data (z hladiska OS).

                        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...
                        • Re: emerge - filozoficky problem 18.01.2007 | 18:17
                          Avatar uid0 Debian  Používateľ
                          > To nic nemeni na fakte, ze DLL je namapovany do virtualneho priestoru procesu a pritom fyzicky je na HDD na tom jednom jedinom mieste...

                          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!
                          Debian. apt-get into it…
                          • Re: emerge - filozoficky problem 18.01.2007 | 18:33
                            Avatar jv openSuSE 11  Používateľ
                            V linuxe je to presne tak isto. Ale od Wlasateho som dostal "poucku", ze to tak nie je. Tak som zistoval dalej a nakoniec som zbadal, ze nemal pravdu.
                            ____
                            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.
                            • Re: emerge - filozoficky problem 18.01.2007 | 18:38
                              Avatar uid0 Debian  Používateľ
                              ja tu uz pisal rozdiel medzi DLL a ELF shared libraries.

                              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...
                              Debian. apt-get into it…
                              • Re: emerge - filozoficky problem 18.01.2007 | 18:57
                                Avatar jv openSuSE 11  Používateľ
                                Este raz... Nemuseli sme nic riesit, keby si napisal, ze predpoklad spravny nie je. Ale to si nespravil (zial), preto sme sa zamotali. Ja som sa ta spytal, ze ked plati A, potom musi platit B. Tvoja reakcia nebola, ze A neplati, ale ze to tak nefunguje ako si popisal to B. Ja o koze, ty o voze.
                                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. ;-)
                                • Re: emerge - filozoficky problem 18.01.2007 | 19:02
                                  Avatar uid0 Debian  Používateľ
                                  > tak napriklad swapovana stranka bola u teba stranka na disku a u mna stranka ulozena konkretne vo swapovacom oddieli.

                                  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
                                  Debian. apt-get into it…
      • Re: emerge - filozoficky problem 18.01.2007 | 15:47
        Avatar jv openSuSE 11  Používateľ
        "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."

        Tak este raz- ako je teda mozne prepisat subor s kniznicou, ktora sa pouziva, ked "The rest of the image is left on disk"?
        • Re: emerge - filozoficky problem 18.01.2007 | 15:50
          Avatar jv openSuSE 11  Používateľ
          A skusim si odpovedat sam ;-)

          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.
          • Re: emerge - filozoficky problem 18.01.2007 | 18:21
            Avatar uid0 Debian  Používateľ
            priviedol si ma na odpoved na tvoju otazku. (aj ked teraz si nie som isty, ci ta zrovna toto zaujimalo, ako komentujem vyssie ohladne win&dll loading)

            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.
            Debian. apt-get into it…
            • Re: emerge - filozoficky problem 18.01.2007 | 18:51
              Avatar jv openSuSE 11  Používateľ
              Ok, zhrniem to.
              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).
              • Re: emerge - filozoficky problem 18.01.2007 | 19:22
                Avatar uid0 Debian  Používateľ
                > Otvoreny subor teda nie je mozne fyzicky na disku zmenit.

                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...
                Debian. apt-get into it…
                • Re: emerge - filozoficky problem 18.01.2007 | 21:42
                  Avatar jv openSuSE 11  Používateľ
                  Waw. Skusil som, sedi vec... Vdaka za objasnenie.
                  Myslim12, ze tento tvoj prispevok vystihol vsetko.