NTG ale może...

W dniu piątek, 16 czerwca 2017 02:01:18 UTC+2 użytkownik Bytomir Kwasigroch napisał:

Nie musisz kupować bajki. Kup maline i zrob jej zdjęcie. Zwiśnie.

Sprawa jest udokumentowana i zbadana.

W dniu 16.06.2017 o 02:01, Bytomir Kwasigroch pisze:

Masz niewierny Tomaszu:

użytkownik snipped-for-privacy@gmail.com napisał:

Ok masz racje, trochę namieszałeś z tym akrylem. To nie akryl tylko krzem, ICek bga z kulkami od spodu. Sam krzem jest nieprzeźroczysty, ale struktura jest od spodu do tego nieosłonięta i padające światło zakłóca pracę U16.

użytkownik Zbych napisał:

Dzieki, widziałem na YT jak laserem świeci po układach. Ktoś zauważył dopiero w 5 tej wersji i poprawili już w 6 tej. Na tyle sprzedanych egzemplarzy:) Ale i w v. 6 tej jeszcze jeden taki układ pozostał w projekcie.

Dnia Wed, 14 Jun 2017 13:06:06 -0700 (PDT), snipped-for-privacy@gmail.com

Ale mnie o co innego chodzi. Ladujemy biblioteke z pliku do RAM. Potem nam Ram brakuje, to sobie wyrzucimy pare stron na dysk, zeby w razie potrzeby zaladowac z powrotem.

Po co zapisywac na dysk, skoro te dane juz na dysku sa, w pliku, z ktorego zaladowalismy ?

Czy linux tak robi z bibliotekami, to nie moge sie doczytac.

J.

W dniu piątek, 16 czerwca 2017 13:25:41 UTC+2 użytkownik J.F. napisał:

Standardowo tak nie robi. Idea byla by fajna ale "rozdzielczosć" zarządzania takimi danymi jest na poziomie biblioteki.

No i dziś to raczej niepotrzebne. Nawet zegarki maja pewnie więcej niż 64MB ram. (do sprawdzenia, z tanich nie udało mi sie w specyfikacjach nic znaleźć)...

Biblioteki raczej nie są strasznie opasłe i nikomu sie nie che dłubać.

Ale może jak niebawem mikrokontrolery zgrubną bardziej (armowe już sie kwalifikują) i hobbysci zaczna uzywac częsciej linuxa zamiast samemu pisać to takie cos sie pojawi?

Dnia Fri, 16 Jun 2017 04:37:03 -0700 (PDT), snipped-for-privacy@gmail.com

Chodzi mi po glowie, ze tak sie robilo z programami, tzn z ich segmentem kodu. W koncuco to za roznica zapisac ze strona pamieci jest w pliku swap pod offsetem X ... albo w innym pliku pod offsetem X..

Ale jak juz mamy taki mechanizm, to czemu nie zastosowac i do plikow bibliotek ? Tylko biblioteka przy zaladowaniu moze wymagac troche pracy (relokacje np) i to moze utrudniac/pozbawiac sensu.

To akurat bylo z mysla o powaznych procesorach, z MMU i pamiecia wirtualna. No ale skoro jest swap to chyba i VM jest ?

J.

W dniu piątek, 16 czerwca 2017 14:31:47 UTC+2 użytkownik J.F. napisał:

To chyba watek w temacie com vs exe. com musialy byc ladowane w calosci. exe od jakiejs wersji mogl byc ladowany czesciowo do pamieci. Ale nie wiem czy czesciowo oznacza ze reszte se musi załadowac sam jak mu trzeba. Bo tam w exe-ku resource byly. Ale zeby sie wypowiedziec to na tyle nie grzebałem

Tak czy siak swapa jest na tyle ze taka akcja jak opisalem to nawet dzis dziala. Ale niestety jak trzeba przemiatac duzo danych do i z swapa to i tak sie sypie. To w kontekscie tej terrarii.

A tu nie wiem czy przypadkiem program nie moze se zazyczyc aby pamiec nie byla swapowana.

Dnia Fri, 16 Jun 2017 05:42:55 -0700 (PDT), snipped-for-privacy@gmail.com

A to nie wiem, ale w systemach z VM nie ma potrzeby, aby calosc ladowac do pamieci od razu. Rownie dobrze moze byc 1 strona.

W unixach jeszcze ciekawiej, bo ludzie z zalozenia uzywaja czesto tych samych programow, to moga wykorzystywac kod juz wczesniej zaladowany przez inny proces.

Ano, cudow nie ma, mnie tylko chodzi o sensownosc zakladania swapa w systemach na SSD/Flash. Jesli pomoglo ... to czy aby na pewno na bilbioteki zabraklo miejsca.

J.

Nie rozumiem kontekstu pytania. Biblioteki .so używają mmap. Text jest mapowany w przestrzeń (wirtualną) pamięci każdego procesu, który wymaga kodu danej biblioteki. W ten sposób oszczędza się ram (wykonywalny), mimo że jest kilka procesow, każdemu się wydaje, że ładuje konieczny fragment kodu biblioteki w swoją przestrzeń adresową ale de facto kernel ta prywatną przestrzeń mapuje w jeden adres fizyczny, gdzie zaladowano bibliotekę.

No to kontekst jest taki, ze jesli ktos uwaza, ze plik swap pozwola mu uwolnic RAM, bo nieuzywane biblioteki system zrzuci na dysk, ten IMO sie myli, bo system nigdy ich do swapa nie zrzuci, bo po co, skoro juz sa w pliku na dysku ? Tylko wywalic z pamieci rzeczywistej (tzn uzyc strone do innego celu, moze wyzerowac), w razie potrzeby sie zaladuje ponownie z pliku.

I swap w tym przypadku nic nie daje.

Tylko znow spytam o relokacje - jesli da sie napisac biblioteke tak, ze nie trzeba zmieniac zadnego adresu w programie, to swietnie. Gorzej jak procesor na to nie pozwala, i przy zaladowaniu pod konkretny adres trzeba zmienic adresy w kodzie. To wtedy mmap nie wystarczy.

W dniu piątek, 16 czerwca 2017 19:41:18 UTC+2 użytkownik J.F. napisał:

Czy zakładasz ze ten kod nigdy wykonany nie był? Bo w zaurusie scenariusz byl taki ze on sie bootował, zuzywal prawie caly ram, potem po wlaczeniu swapa ten swap sie zapelnial pi*oko w polowie (jakies 32MB) a pamieci na bufory/free bylo podobnie (okolo 32MB).

Tylko po co? Skoro ten kod byl wykorzystywany albo raz po stacie albo na tyle okazjonalnie ze nie bylo to uciazliwe dla karty?

W zaurusue dawało/daje (nie korzystałem od paru lat, ale w szufladzie leży...)

Przedpiścy chodziło o to ze biblioteki są mapowane i praktycznie mając 10 programów i kazdy korzysta z biblioteki 1MB tak naprawde mamy zajęte 1MB realnie plus jakieś dodatkowe kilobajty/megabajty na dodatkowe dane w rodzaju miejsca roboczego biblioteki (bo np. jakies dane robocze trzeba zapisac ale nie jest dobrze ich współdzielić), choc tu trudno sie spierac czy to dane biblioteki czy programu (np. jakiś klucz ssh, bufor do komunikacji itp..)

W dniu piątek, 16 czerwca 2017 18:46:06 UTC+2 użytkownik Marek napisał:

Jarosławowo chodzi o to ze jesli biblioteka zawiera 100 funkcji i 20 z nich jest wykorzystywane często, 20 jednokrotnie przy bootowaniu systemu a 60 nie wykorzystywane wcale to fajnie bylo by aby te pierwsze 20 bylo w ram, drugie 20 w swap a te 60 aby siedziało na dysku.

Albo jeszcze lepiej jakby te drugie 20 też mogło być wykasowane z ram.

W praktyce tak sie dzieje ale tylko jak program korzystajacy z biblioteki sie skonczy. Ale jak sie nie kończy (init, jakiś demon) to cała biblioteka okupuje ram/swap.

Dnia Fri, 16 Jun 2017 11:24:23 -0700 (PDT), snipped-for-privacy@gmail.com

Nie, tego nie zakladam

No to tym lepiej - nie trzeba bedzie ladowac ponownie.

Chodzi mi tylko o to, ze jesli to jest kod (text w terminologii unixowej) programu czy biblioteki, to nie trzeba do z pamieci na dysk do pliku swap zapisywac, bo on juz na dysku jest - tylko w innym pliku. Jak Marek pisze, ze biblioteki sa przez mmap mapowane, to tym bardziej.

Wiec skoro dane nie sa pliku swap zapisywane, to plik niepotrzebny :-)

Byc moze tam bylo cos inaczej. Albo to inne dane zajmowaly pamiec, i one musialy byc w swapie.

A mnie chodzi o to, ze kod moze zawierac pewne adresy, ktore przy zaladowaniu pliku pamieci musza byc ustawione odpowiednio. I juz prosty mmap odpada, a moj pomysl jest niemozliwy, lub sie bardzo komplikuje.

Tego biblioteki nie powinny miec, ewentualnie alokowane w ramach procesu uzytkownika.

J.

Dnia Fri, 16 Jun 2017 11:27:13 -0700 (PDT), snipped-for-privacy@gmail.com

Nie, mnie chodzi o to, ze nie trzeba drugich 20 zapisywac do swap, skoro one sa dostepne w pliku, jak te 60.

Co system uzywajacy pamiec wirtualna zrobi, jak stwierdzi, ze juz dawno nie byly uzywane. Tylko proponuje nie zapisywac ich wtedy do swapa ... bo po co, w razie potrzeby mozna z oryginalnego pliku pociagnac.

Chyba widze sposob na sprawdzenie - uruchomic program korzystajacy z biblioteki gdzies na karcie lub na osobnej partycji ...i odmontowac ja. Pozwoli system odmontowac, czy powie, ze uzywana ? A w razie odlaczenia na sile ... scrashuje program szybko ?

J.

Zależy jak biblioteki były zbudowane. Po drugie swapowane są strony a nie całe "biblioteki". Czy strona jest swapowalna decyduje o tym kilka czynników. Biblioteki skompilowane bez -fPIC mogą być swapowane bo nie są “shared“ (brak mapowania dysk-ram). Biblioteki z -fPIC (z reguły większość) są mmapowane i ich strony nie są swapowane. Więcej szczegółów:

tak

tak, ale tylko gdy nie była załadowana cała a program (ld.so) poprosi o resztę.

Ja bym to inaczej sformulowal (i byc moze sie pomylil): biblioteki PIC nie musza byc swapowane, bo (jak pisalem) mozna je zaladowac ponownie z pliku. Te mmapowane chyba wrecz nie moga, bo to sie troche kloci z koncepcja mmap. A te bez -fPIC, gdy zabraknie pamieci, to musza byc swapowane. Bo zawartosc pamieci nie odpowiada zawartosci pliku.

O w morde - narzekamy na innych, a readline ma 2MB ?

Co tam robia te dwa segmenty dirty ?

J.

J.F. zaczynas odkrywać Linuxa? Myślę, że jakieś minimum 20 lat za późno....