Memória töredezettség- mentesítés

Címkék

Marcelo Tosatti tegnapi levelében egy olyan patchet postázott az LKML-re, amely a memória defragmentálását hivatott elvégezni.Marcelo munkája egy coalesce_memory() névre hallgató függvényt implementál, amely "zone" és "order" paramétereket vár.

A kód nincs még teljesen kész, SMP környezetben vannak még vele problémák, de egy processzoros rendszereken már szépen működik (pár percig :-) és könnyedén hoz létre nagy, fizikailag egybefüggő memória-területeket.

Marcelo levele itt.

Hozzászólások

hm, és miért lesz jó ez nekünk? ;-)

Mert ha jól sejtem, akkor egy process a saját magának allokált memóriát növelni, vagy új területet allokálni csak úgy tud, ha rendelkezésre áll elegendően nagy szabad memóriarész. Vagyis ha a memórián belül szabad memória, csak kis apró darabokban van, akkor a legnagyobb méretű processz, amit indítani tudsz, az elég szorosan korrelálni fog a legnagyobb szabad memóriadarab méretével.

Szerintem a ketszintu cimzes miatt erre nincs szukseg, ugyanis a lefoglalt memorianak csak a virtualis cimterben kell folytonosnak lennie, a fizikai memoriaban szanaszet is lehet. A virtualis cimter viszont 2 v. 4 giga es az szerintem nem nagyon fragmentalodik. Bar ha nagyon erolteted, akkor biztos azt is el lehet "rontani".

Inkabb a jobb cache kihasznaltsagot sejtem a dolog mogot, mert a kevesbe toredezett fizikai memoria kevesebb cache misst okozhat. Pl. a mai taposabb asztali processzorokban is van 1MByte L2 cache, nem mindegy, hogy ennek mekkora resze ertektelen memoriaszemet.

Andrei

Igen... De nem mindig elég 2G egy processznek...

Láttam már al3x-et azért kernelt pecselni, mert vmi. jávás okádéknak kevés volt a 2G processz adatterület, és 32 bites volt az architektúra... És némi trükközéssel elérte, hogy az adatterületük 3G lehessen :-)

Mondjuk 64 bites architektúráknál már kicsit másak a korlátok...

De ettől függetlenül: ép ésszel belegondolva, ha a fizikai memóriában töredezettek a részek, akkor nem csak a cache miss a gond, hanem az, hogy az "overhead" is sokkal nagyobb...

Mert ugye ha pl. 1 darabban van x. mennyiségű memória, akkor kell vhova 1 entry, hogy azt megtaláld a fizikai memóriában... ha meg 200 darabban, akkor kell hozzá 200 entry... amiben keresni kell... a fragmentek mérete se feltétlen egyforma. így egy azon belüli cím keresésekor ráadásul csak lineárisan tudsz keresni az entryk közt, stb...

"jávás okádék".

Hehe ez jo.... Javapower. Ugy latom nem csak en kerulom

Szerintem a fizikai memoriabol kb. 32-256bites reszekben jon be a memoria (az interfesztol fuggoen), a jellemzo ertek talan 64bit. Ennel nagyobb reszt alapbol nem tudsz behuzni. Ugyhogy mindegy, hogy fizikailag hogy helyezkednek a dolgok.

Mondjuk vannak ilyen burst mode meg ilyen lehetosegek, ezeket sajnos nem ismerem.

Andrei