Tvikanje Gnu/Linuxa

Nema. Glibc malloc interno koristi brk() i mmap() za kontrolu veličine heapa iz kojeg dodjeljuje memoriju, a ne kmalloc.

Ne.

Ali malloc ne poziva pri svakoj alokaciji brk() i mmap(). Malloc funckionira kao nekakav memory pool, sa brk() se taj pool rasteže po potrebi.

brk() je veoma rudimentarna funkcija koja služi za jako grubu kontrolu, i spada pod VMM kako bi mu se moglo reći koliko memorijskih stranica još treba dodijeliti virtualnom adresnom prostoru nekog procesa. malloc "sjecka" (u nedostatku bolje riječi) taj adresni prostor i onda vraća pokazivače na pojedine komade. Fragmentacija se pojavljuje u virtualnom adresnom prostoru zbog tog rezuckanja, jer se od malloca mogu zatražiti svakakve veličine, dok VMM radi sa fiksnom veličinom - onom jedne memorijske stranice.

Dakle da rezimiramo:

• VMM ne obavlja alokacije unutar virtualnog adresnog prostora, on alocira memorijske stranice fizičke memorije i dodjeljuje ih i oduzima tom virtualnom adresnom prostoru po potrebi.
• malloc sjecka virtualni adresni prostor i vraća pokazivače na te komade, te po potrebi govori VMM-u da treba virtualnom adresnom prostoru nekog procesa dodijeliti još memorijskih stranica.

Koliko ti puta moram reći da to nije nikakva ušteda u praksi? Je, brojke su možda i niže, ali dobitak u perfomansama je ravan nuli. Firefox zapravo ne "troši" manje nego si mu samo smanjio resident size, što samo po sebi nije od značaja jer bi mu resident size ionako potkresao i veći pritisak na memoriju kod bilo kojeg kernela (bio on "optimiziran" ili ne). Te memorijske stranice koje si mu uklonio iz RAM-a nisu isparile (dobro možda i jesu ako su bile čiste, ali one ionako kao da i ne postoje), nego se moraju premjestiti na neku drugu memoriju (swap?).

@boldano: LOL, ne odustaješ je li?

Itekako imaju veze. Puno resursa = veliki memorijski pritisak = malo slobodne memorije = masovni swapping = loše perfomanse = koma.

Dakle ti si pokušajem umanjivanja uporabe memorije u konačnici imao za cilj poboljšati perfomanse, odnosno ukloniti visoki pritisak na memoriju.

No nebitno, kako god ti to nazivao, nisi zapravo dobio ništa osim varljivo niske "resident" brojke.

Ali to nije zbog niže alokacije radne memorije. Ja se ovdje bavim sa navodnim dobitcima uslijed niže uporabe RAM memorije. Ovi ostali dobitci mi nisu od interesa niti su razlog mog piskaranja u ovoj temi, nego me ovo sa memorijom baš bolo u oči.

Ne, ne troši ti manje (memorijskih) resursa. Ali mogu ja ovako do sutra ponavljati, ako ti do sada nije "sjelo" onda niti neće...

joj, joj...

Ajd laku noć/dobro jutro (što god ti draže)

Živo me zanima što bi se desilo da otvori GIMP i u njemu otvori sliku 25000x19000 pixela. Odnijela bi oko 2 GB rama, no po njegovom bi odnijelo koliko, maksimalno 300 MB :)

O boze dragi

kao prvo slikice se ne mogu obrisati iz poruke, da mogu obrisao bi i njih

Tako da ihushu, svoje lazi da se u nekoj slici vidio swap pricaj drugdje i na kraju nikad se nije vidio swap jer nikad nisam slikao sto je mountano

Kao drugo vidim da niti ne znas sto je swap jer i da ga imam on se ne bi koristio na 400mb memorije.

Koji ste vi ej, spremni svojim kretenizmom unistiti svaku temu. Zasto ?

jer vam smeta to st mi trosi manje memorijie i brze radi ? imate probleme u vezi toga ?

a dobro, evo sta bi bilo na slici od 11 000 pixela:

http://i62.tinypic.com/29f82up.jpg

dok se u mount jasno vidi da kernel ne koristi swap

Nema rijeci da opisem vas idiotizam. osim jedno veliko HVALA na unistavanju teme jer vam smeta to sto neko ima brzi i po resure efikasnij sustav. Svijet je zaista proklet

Barem priznaj koliko je cijelih seknuda brze izvodjeje aplikacija, hebo te layman sa ubodima od 250ms

Da ste vi iz zabave probali komajlirati kernel ne bi tu u temi pricali nebuloze

Koji je tvoj problem? I opet u htopu ne vidim koliko je GIMP pojeo memorije, a i slika ti je malešna, valjda si ju tak konfigurirao da ne ide u swap. 25000x19000, cijeli htop da vidimo stanje, pa se onda hvali. može i 30000x21000, da bude malo preko 2 GB, koliko RAMa imaš.

Što je bilo, umro bi ti stroj? 11000x11000 slika kod mene uzme oko 550 MB. Boje su ti u kujcu, hackerske, još jpegom komprimirane tak da se niš ne vidi.
Kod kolege duplo, pretpostavljam zbog undo funkcije.

Čuj, ta ljubomora zbog optimizacije kernela... a reci, kernel se ne nalazi u nekakvom hardveru, i ne izvršava se u procesoru? Obzirom da kažeš da on to radi bez ikakvog hardvera...? Podsjećaš me na jednog čovjeka, audiofilčeka, koji je napisal audiofilski audio player savršenih performansi, engine se cijelo vrijeme nalazi i izvršava u procesorskom cacheu... tak je on rekel, e sad, on je kakti programer, pa valjda on to zna, a mi, kaj malo natucamo po hardveru i softveru već godinama, mi bismo mu morali na riječ vjerovati, gospon programeru, ne...?

Teško je reći zašto je duplo, možda nam se verzije ne poklapaju. No to je zapravo nebitno, jer mi ovdje pričamo o tome da OS "mora" honorirati zahtjeve za memorijom neke aplikacije, jer u protivnom ta aplikacija ne može raditi sa tim konkretnim zadanim parametrima. A takvi zahtjevi za memorijom se onda moraju primijetiti u htopu, i sva memorija mora biti prebrojana i znati točno kamo je otišla. Jer podatci jednostavno ne mogu netragom iščeznuti u atmosferu, i onda se magično pojaviti točno kada su potrebni kako se aplikacija ne bi skršila.

To je kao zakon o očuvanju mase u kemiji. Ukupna masa sa lijeve strane mora biti jednaka ukupnoj masi sa desne strane jednadžbe, ne može ništa magično nastajati i netragom nestajati.

-na konkretnoj slici, korišteno je bilo 4xxMB RAMa, swapa 0 (ako se sjećam imaš 1.5GB.. swap 0/2863MB). Precizno, ja kažem da ga imaš (ti navodiš da ga nemaš), u tom trenutku ga ne koristiš. Izmišljen podatak?

-tko laže? Zašto? Pogotovo jer je vidljivo da znaš na što se odnosi... (moguće da je slika bila na linku... ne mora biti u postu).

edit: (test)

neke dvije slike.

pa brisanje prve.

radi. Dakle obrisao si sliku sa swapom. Imaš ozbiljnih problema (neki to nazivaju kemijski disbalans).

Tako je

Jer u linuxu je sva memorija virtualna, sta ti tu nije jasno.

Memorija je mapirana u kernel i nije stvarna fizicka vec je mapa stvarne memorije. Ti mislis da je gimp operativni sustav a ne linux, tocno tako to gledas

Gimp u linuxu samo koristi virtualno memoriju kao i svaka druga aplikacija jer koriste ogledalo fizicke memorije u kernelu a ne konkretnu fizicku mem

Evo nasao sam link u kojem ti sve pise

In Linux, user memory and kernel memory are independent and implemented in separate address spaces. The address spaces are virtualized, meaning that the addresses are abstracted from physical memory (through a process detailed shortly). Because the address spaces are virtualized, many can exist. In fact, the kernel itself resides in one address space, and each process resides in its own address space. These address spaces consist of virtual memory addresses, permitting many processes with independent address spaces to refer to a considerably smaller physical address space (the physical memory in the machine). Not only is this convenient, but it's also secure, because each address space is independent and isolated and therefore secure.

http://www.ibm.com/developerworks/library/l-kernel-memory-access/

I sad zamisli kernel sa nepotrebnim kalkulacijama i cachevima, prevelikim defaultnim adresama dali stvarnih od kernela ili virtualnih od aplikacija, velik pa spor, fragmentiran,... koji ima podrsku za mnoge alokatore, schedulere,... i puno drugacijih opcija kojima si ih zapravo konfiguiras u kojem god smjeru hoces, pogotovo sa nekim specijalno patchiranim kernelima

Sta mislis koliko mozes utijecati na mapiranje i virtualno adresiranje sustava i svih aplikacija i kolko mozes utijecati na potrosnju te fizicke memorije.

Ili iz linka

 The hardware itself provides the mapping, but the kernel manages the tables and their configuration

U pravu si da je linux caroban, zbog boldanog

A kernel je učitan u bateriju pretpostavljam. 

Ti definitivno ne razumiješ koncept virtualne memorije, btw. kakva je to izjava? Pa i pod windowsima je sva memorija virtualna, kao i pod više-manje svim ostalim popularnim operacijskim sustavima.

Samo zato što proces ima svoj virtualni adresni prostor, ne znači da su njegovi podatci smješteni negdje u eteru, ne, oni i dalje moraju biti fizički negdje pohranjeni (bili to memorijski čipovi, hard disk, ili nešto treće, svejedno je).

Evo složio sam ti jednu infografiku koja ilustrira princip virtualne memorije.

teaser :P