Divne chovani mallocu

[Martin Macok]

On Fri, 29 Oct 1999, Martin Macok wrote:

> On 29 Oct 1999, Cejka Rudolf wrote:
> 
> > Jeste maly dodatek: Nejspis jsme si trochu nerozumeli v pojmu
> > "namapovani". Ja jsem mel na mysli zarazeni pametove stranky
> > do adresoveho prostoru procesu a pripravu pro jeji pripadne
> > odswapovani (i v pripade modelu cela pamet = RAM + Swap ... on se
> > uz stejne jiny nepouziva)). Fyzicke pripojeni konkretni stranky
> > uz jsem povazoval za neco jineho.
> 
> Pravda, trochu jsme psali kazdy o necem jinem. Parkrat jsem pouzil
> nespravne termin "namapovani" ... 
> 
> Pri alokaci tabulka stranek adresoveho prostoru procesu vyplni s
> prislusnymi flagy (stranky byla alokovany, ale zatim nebyly pouzity,
> obsahuji nedefinovane hodnoty - proste se jenom vyplni tabulka, nic vic)
> ...  (koumnul jsem do src (2.2.13) a vykoukal jsem to tak - nejsem kernel
> guru a je mozne, ze se v necem pletu) - Asi by bylo vhodne, aby do teto
> debaty vnesl svetlo nekdo kompetentnejsi ...
> 
> Co myslite konkretne pripravou na odswapovani? 
> 
> Jestli tomu dobre rozumim (nerad bych vam neco podsouval), tak vam vadi
> tyto 3 veci:
> 
> 1) ze se ty stranky rovnou nejsou asociovane s realnou fyzickou adresou?
> Ze takto malloc-ovane stranky na zacatku proste nikde ve fyzicke pameti
> neexistuji?
> 
> 2) pri alokaci se nekontroluje velikost volne pameti proti velikosti RAM +
> SWAPu, ale pouze oproti free_mem_end_ptr (0x90000 na i386)?
> 
> 3) jakym zpusobem pracuje s takto alokovanou neinicializovanou pameti?
> (viz priklady nize)
> 
> > Pro zajimavost si zkuste treba toto:
> > 
> > a = malloc(XXX);
> > b = malloc(XXX);
> > kopie dat z a do b
> > 
> > proti
> > 
> > a = malloc(XXX);
> > inicializace bloku a
> > b = malloc(XXX);
> > kopie dat z a do b
> > 
> > V prvnim pripade byla (2.0.35) kopie bloku dat na mem starem pocitaci
> > v Linuxu 4x rychlejsi nez druhy pripad. Fyzicke moznosti rychlosti
> > kopie pameti pritom presne odpovidaly pouze druhemu pripadu.
> 
> Domnivam se, ze v tom prvnim pripade Linux vi
> (?vm_area_struct.vm_flags?), ze zachazi s takto alokovanou pameti (s
> nedefinovanym obsahem) a "nejak to proste osuli" - fyzicky neprovadi zadny
> presun dat ...
> 
> Pokud se mylim a mystifikuju, tak se hluboce omlouvam a prosim, aby me
> nekdo opravil.

Odpovim si sam ;-)

ad (2) (za behu systemu) Da se nastavit (myslim, ze az v jadrech >=2.1.x),
zda kernel ma kontrolovat velikost alokovane pameti (oproti velikosti RAM
+ SWAP), nebo se ma porad tvarit, ze je pameti dostatek. Viz:  

/usr/src/linux/Documentation/sysctl/vm.txt
/proc/sys/vm/overcommit_memory
/usr/src/linux/mm/mmap.c : int vm_enough_memory(long pages)

(Myslim, ze 2.0.x je volani malloc vzdycky uspesne)

Snad jsem to jeste vice nezatemnil ... Kazdopadne na 2.2.13 s nepovolenym
/proc/sys/vm/overcommit_memory (0) mi to dovoli jednorazove malloc()-ovat
pouze tolik pameti, kolik zvladne moje RAM + SWAP ...
Na druhou stranu mi ale dovoli alokovat spoustu mensich useku (ktere
nepouzivam), takze to zase neresi vsechno ...

-- 
< Martin Mačok    (e) martin.macok na underground.cz  <ISO-8859-2-compatible> 
 \ (h) http://kocour.ms.mff.cuni.cz/~macok/  (w) http://underground.cz/ /
   \\\\\            any OS that doesn't make me look              /////
     \\\  like a random mouse-clicking idiot is a Good Thing (c)  ///