- A hozzászóláshoz be kell jelentkezni
- 2546 megtekintés
Hozzászólások
hm, és miért lesz jó ez nekünk? ;-)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
KDE userek örülni fognak ;))
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
A memoriaban az egymas utani rekeszek cimzese gyorsabb, mint a random cimzes.
Persze lehet, hogy ez mar regota nem igaz, nem vagyok kimondottan up to date a hw (melyebb szintu) mukodesebol:)
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
"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
- A hozzászóláshoz be kell jelentkezni