[so] malloc examen

[Octavian Purdila]

On Saturday 17 February 2007 02:09, Gringo Croco wrote:
> discalimer: spun urmatoarele doar din principiu, daca primesc sau nu
> punctaj la problema asta nota nu mi se schimba.
> 
> that being said, din textul problemei 6 de la examen:
> 
> fie un sistem pe 32 biti cu 1GB de RAM si urm. secv de cod:
> printf("eroare: %d\n", malloc(512*1024*1024)==NULL?1:0);
> printf("eroare: %d\n", malloc(512*1024*1024)==NULL?1:0);
> printf("eroare: %d\n", malloc(512*1024*1024)==NULL?1:0);
> ce se afiseaza?
> 
> 
> din man malloc(3) (pe ubuntu 6.6) sectiunea BUGS:
>        By default, Linux follows an  optimistic  memory  allocation  strategy.
>        This  means  that  when malloc() returns non-NULL there is no guarantee
>        that the memory really is available. This is a really bad bug.  In case
>        it  turns  out  that the system is out of memory, one or more processes
>        will be killed by the infamous OOM killer.
> 
> acum, ce contest eu este faptul ca problema nu specifica nicaieri ca e
> vorba de un linux care are bugul asta.
>

memory overcommit este considerat in egala masura un feature. Parerile sunt impartite. Majoritatea sistemelor Unix permit atat overcommit cat si non-overcommit tocmai pentru ca in unele situatii o abordare este mai buna, iar in altele cealalata este mai buna.

O comparatie, oarecum tendentioasa, gasiti la:

http://developers.sun.com/solaris/articles/subprocess/subprocess.html

Windows-ul intra si el in categoria SO ce nu permit overcommit.


> sincer pana in seara asta nu stiam ca referentiind un pointer aflat in
> rangeul alocat de malloc(3) pot avea un segmentation fault.
> 
> 
> acum ce zic eu ca ar fi corect:
> a) sa se anuleze penalizarea pentru subiectul in cazul celor care au
> mentionat diferente de output in cazul in care exista swap sau nu si
> au zis ca e posibil sa se aloce cei 1.5GiB RAM

Ce vroiam sa aflu de la voi cu aceasta intrebare era daca ati inteles una din principalele aplicatii in SO ale memoriei virtuale: demang paging. Atunci cand SO aproba o cerere de alocare/mapare de memorie, nu inseamna ca memoria fizica se aloca efectiv, ci doar ca se creaza maparile in spatiul de adresa al procesului. Ulterior, la accesari ala paginilor din spatiul de adresa, acestea se vor aloca efectiv. (lucrul asta e valabil la toate SO, indiferent daca avem overcommit sau nu)

Problema overcommit-ului este una diferita. Lasam sau nu lasam ca un proces sa mapeze in spatiul de adresa o zone de o dimensiune ce nu poate fi sustinuta de memorie fizica + swap? Daca overcommit-ul se identifica practic cu demand paginig-ul, non-overcommit-ul = demand paging + overcommit checking. 

Intr-un context practic, raspunsul la intrebare trebuie sa tina cont atat de demand paging cat si de overcommit. Intr-un context teoritic, cel al examenului, nu era necesara si descrierea situatiei non-overcommit, ci doar cea a demand pagining-ului. 

> b) sa nu se scada nicaieri in teme daca nu se verifica daca malloc(3)
> intoarece sau nu NULL (desigur doar pe linux) intrucat mallocul de pe
> linucsi returneaza NULL doar cand primeste un parametru mai mare sau
> egal cu 4GiB sau 0.
> 

head Documentation/vm/overcommit-accounting -n 20

The Linux kernel supports the following overcommit handling modes

0       -       Heuristic overcommit handling. Obvious overcommits of
                address space are refused. Used for a typical system. It
                ensures a seriously wild allocation fails while allowing
                overcommit to reduce swap usage.  root is allowed to 
                allocate slighly more memory in this mode. This is the default.

1       -       Always overcommit. Appropriate for some scientific
                applications.

2       -       Don't overcommit. The total address space commit
                for the system is not permitted to exceed swap + a
                configurable percentage (default is 50) of physical RAM.
                Depending on the percentage you use, in most situations
                this means a process will not be killed while accessing
                pages but will receive errors on memory allocation as
                appropriate.

Exista deci posibilitatea ca Linux-ul sa ruleze in mod non-overcommit.

tavi