On Fri, 16 Jun 2017 13:25:58 +0200, "J.F."
<j...@p...onet.pl> wrote:
> 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.

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ę.

--
Marek

do góry

Dnia Fri, 16 Jun 2017 18:45:24 +0200, Marek napisał(a):
> On Fri, 16 Jun 2017 13:25:58"J.F." <j...@p...onet.pl> wrote:
>> 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.
>
> 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.

http://eli.thegreenplace.net/2011/08/25/load-time-re
location-of-shared-libraries

J.

do góry

W dniu piątek, 16 czerwca 2017 19:41:18 UTC+2 użytkownik J.F. napisał:
> Dnia Fri, 16 Jun 2017 18:45:24 +0200, Marek napisał(a):
> > On Fri, 16 Jun 2017 13:25:58"J.F." <j...@p...onet.pl> wrote:
> >> 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.
> >
> > 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 ?

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 wywalic z pamieci rzeczywistej (tzn uzyc strone do innego celu,
> moze wyzerowac), w razie potrzeby sie zaladuje ponownie z pliku.
>

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

> I swap w tym przypadku nic nie daje.
>

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

> 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.
>
> http://eli.thegreenplace.net/2011/08/25/load-time-re
location-of-shared-libraries
>
>

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..)

do góry

W dniu piątek, 16 czerwca 2017 18:46:06 UTC+2 użytkownik Marek napisał:
> On Fri, 16 Jun 2017 13:25:58 +0200, "J.F."
> <j...@p...onet.pl> wrote:
> > 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.
>
> 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ę.
>
>
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.

do góry

Dnia Fri, 16 Jun 2017 11:24:23 -0700 (PDT), s...@g...com
> W dniu piątek, 16 czerwca 2017 19:41:18 UTC+2 użytkownik J.F. napisał:
>> Dnia Fri, 16 Jun 2017 18:45:24 +0200, Marek napisał(a):
>>> On Fri, 16 Jun 2017 13:25:58"J.F." <j...@p...onet.pl> wrote:
>>>> 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.
>>>
>>> Nie rozumiem kontekstu pytania. Biblioteki .so używają mmap.

>> 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 ?
>
> Czy zakładasz ze ten kod nigdy wykonany nie był?

Nie, tego nie zakladam

> 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 wywalic z pamieci rzeczywistej (tzn uzyc strone do innego celu,
>> moze wyzerowac), w razie potrzeby sie zaladuje ponownie z pliku.
> Tylko po co?
> Skoro ten kod byl wykorzystywany albo raz po stacie albo na tyle okazjonalnie ze
nie bylo to uciazliwe dla karty?

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 :-)

>> I swap w tym przypadku nic nie daje.
>>
> W zaurusue dawało/daje (nie korzystałem od paru lat, ale w szufladzie leży...)

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

>> 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.
>> http://eli.thegreenplace.net/2011/08/25/load-time-re
location-of-shared-libraries
>>
> 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

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.

> mamy zajęte 1MB realnie plus jakieś dodatkowe kilobajty/megabajty
> na dodatkowe dane w rodzaju miejsca roboczego biblioteki

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

J.

do góry

Dnia Fri, 16 Jun 2017 11:27:13 -0700 (PDT), s...@g...com
> W dniu piątek, 16 czerwca 2017 18:46:06 UTC+2 użytkownik Marek napisał:
>> On Fri, 16 Jun 2017 13:25:58 +0200, "J.F."
>> Nie rozumiem kontekstu pytania. Biblioteki .so używają mmap.
>>
> 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.

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

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

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.

do góry

On Fri, 16 Jun 2017 19:41:34 +0200, "J.F."
<j...@p...onet.pl> wrote:
> 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 ?

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:

https://unix.stackexchange.com/questions/116327/load
ing-of-shared-libraries-and-ram-usage

--
Marek

do góry

On Fri, 16 Jun 2017 20:59:01 +0200, "J.F."
<j...@p...onet.pl> wrote:
> ja. Pozwoli system odmontowac, czy powie, ze uzywana ?

tak

> A w razie odlaczenia na sile ... scrashuje program szybko ?

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

--
Marek

do góry

Dnia Fri, 16 Jun 2017 21:41:56 +0200, Marek napisał(a):
> On Fri, 16 Jun 2017 19:41:34 +0200, "J.F." <j...@p...onet.pl> wrote:
>> 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 ?
>
> 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:

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.

> https://unix.stackexchange.com/questions/116327/load
ing-of-shared-libraries-and-ram-usage

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

Co tam robia te dwa segmenty dirty ?

J.

do góry

On Sat, 17 Jun 2017 02:25:40 +0200, "J.F."
<j...@p...onet.pl> wrote:
> O w morde - narzekamy na innych, a readline ma 2MB ?
> Co tam robia te dwa segmenty dirty ?

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

--
Marek

do góry