Se da o masina cu arhitectura x86 (32 bit) cu 4 GB RAM, rulind un kernel recent, compilat cu suport pentru 4 GB RAM.
Din cauza modului in care kernel-ul rezerva memoria, un proces nu poate aloca mai mult de 3 GB, indiferent ce face (restul e rezervat pentru kernel). De fapt, valoarea reala e chiar mai mica de 3 GB. Din cauza asta, un program care vrea sa aloce niste matrici gigantice (peste 2 GB de date) nu poate sa ruleze. Se cere sa se mareasca memoria disponibila pentru procese, pastrind configuratia hardware. Nu se pot folosi arhitecturi pe 64 biti din motive de fonduri. "Spargerea" problemei pe un cluster e exclusa din motive de performanta. Marirea memoriei fizice peste 4 GB iarasi nu merge, pentru ca limita de 3,999...GB per proces ramine valabila (e impusa de arhitectura x86) iar modificarea aplicatiei nu e chiar triviala (licente, etc.). Singura solutie ramine micsorarea memoriei rezervate pentru kernel. Sapind prin kernel, am vazut in include/asm-i386/page.h variabila __PAGE_OFFSET, care pare sa faca exact ce vreau eu: controleaza limita unde memoria e divizata intre kernel- si user-space. Banui ca daca o maresc pe la vreo 0xE0000000 atunci memoria rezervata pentru kernel o sa scada pe la vreo 512 MB, ceea ce ar fi beton. Intrebarea nr 1: asta e singura modificare necesara pentru a schimba raportul intre memoria rezervata pentru kernel si cea pentru procese? Intrebarea nr 2: cam cit de departe, in mod rezonabil, pot sa merg cu micsorarea memoriei rezervate pentru kernel? Probabil ca cache-ul de disc o sa devina mai mic, dar masina aia nu prea face disk I/O, si nu-mi dau seama daca mai sint si alte probleme. -- Florin Andrei "The open source thing works great in a society of mutual respect, in a place where nobody gets too much power. But as soon as things get ugly, it gets unpleasant, and it all starts falling apart." - James Gosling --- Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to unsubscribe from this list.
