linux user group brescia

immagine del castello

Archivio della mailing list

Quantita' massima di memoria per processo/SO ?

Luca Giuzzi giuzzi a lugbs.linux.it
Lun 22 Dic 2003 14:11:32 UTC
On Mon, Dec 22, 2003 at 02:50:07PM +0100, Alfredo Quartini wrote:
> 
> 
> ... qualcosa non mi torna...
> eseguendo uno dei programmini citati, il top mi dice :
> 
>    PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
> 27921 alfredoq  25   0 2168M 2.1G   956 R    99.8 36.5   2:07 gdsinfo
> 
> che è ben al di la' dei 960MB.

Beh... ogni processo vede uno spazio virtuale di indirizzi di 3Gb 
 (la parte di ram mappata kernel space), ma lo spazio fisico (RAM) che
 esso ha direttamente accessibile e' poco meno di 1Gb [poco meno in 
 quanto c'e' lo stack e ci sono le librerie dinamiche]

> 
> La mia domanda è: indipentemente dalla massima quantità di memoria 
> allocabile da un singolo processo, dovendone eseguire tre o quattro 
> contemporaneamente di tipo quello sopra, avere 6GB di memoria fisica 
> dovrebbe servire a qualcosa invece che averne "solo" 4GB ?
> 
Piu' ram hai, meglio e' :))
D'altro canto il guadagno che hai passando da 4 a 6 Gb e' minimo in
quanto la memoria restante e' accessibile solo come "memoria alta"
(si', assomiglia a quanto si vedeva sotto DOS... in effetti il
PAE e' un sistema di paginazione, anche se la P nell'acronimo 
ufficialmente sta per Physical e non per Paged) che deve essere
mappata di volta in volta nello spazio indirizzi della CPU.


> questo è parte di quello che ho trovato in giro:
> 
Attento questa e' documentazione vecchia... in particolare
 CONFIG_HIGHMEM_4G 
 non altera piu' la posizione dello split kernel/userspace
 che resta 3:1.
 [3 Gb di address space per i processi/1 Gb di RAM permanentemente
  accessibile]

> Physical Memory
> Physical memory above 1GB is known as the high memory zone [USE]. In 
> earlier 2.2.x releases, this was the maximum amount of physical memory 
> the kernel could use unless it were customized. By 2.2.17 this memory 
> could be accessed by setting the CONFIG_HIGHMEM_4G option which moved 
> the kernel down from 3GB to 2GB. This also cuts down the memory 
> available to any single process however [YAN]. If the CONFIG_HIGHMEM_64G 
> option is selected, then PAE is turned on and the kernel can access up 
> to 64GB of RAM. This support must be compiled into the kernel [CONF]. 
> However, even though your machine may support greater than 4GB of 
> memory, no user process can use more than 4GB of memory at a time 
> (again, the 32-bit pointer limit).

Questo non e' vero nel senso in cui ti piacerebbe, purtroppo...
 il limite per un processo e' necessariamente piu' basso di 4Gb
 (c'e' il kernel!!)

> Even though pointers are still only 32-bits wide, the kernel can access 
> all of physical memory by changing the values in the top-level directory 
> (pgd) or by changing the base address of the pgd by moving a new value 
> into register CR3[PPR]. (Note that changing CR3 invalidates the entire 
> TLB, and a task switch changes the CR3 [PPR].)
> 
Argh... questo e' un trucco MOLTO sporco... invalidare tutto il 
 Translation Lockaside Buffer
e' una bruttissima cosa... essenzialmente vuol dire che devi ripulire
la cache e che la mappatura pagine_fisiche/pagine_virtuali deve
essere ricalcolata... 

che tipo di kernel stai usando??
[e soprattutto che patches]

> 
> Che mi sembra voglia dire che ***un singolo processo*** può avere uno 
> spazio di memoria fino a 4GB; nel caso di piu' processi di questo tipo, 
> il kernel (con il supporto PAE fornito dal processore) si occupa della 
> paginazione sfruttando "tutto quello che c'e' in piu'" per garantire che 
> tutti i processi siano felici e contenti...
> 
Il trucco descritto sopra (lo ripeto) ha degli effetti non indifferenti
sulle prestazioni e si presta ad esporre dei bachi non di poco conto...
tendenzialmente quello che perdi col l'invalidazione del TLB non lo
riguadagni certo con lo "swap mediante PAE".
Puo' funzionare, ma la cosa mi sorprenderebbe, soprattutto con
programmi "generali".

Il modo piu' semplice per avere piu' ram per un processo e' quello
(cui accennavo prima) di portare lo split kernel/userspace a 2:2 Gb.
In questo modo hai 2Gb di ram permanentemente mappati e 2Gb di 
spazio indirizzi accessibili dal tuo programma. 

ciao, 
lg
> Ho capito male ?
> 
> Alfredo.
> 
> andrea gelmini wrote:
> > On Mon, Dec 22, 2003 at 11:33:22AM +0100, Alfredo Quartini wrote:
> > 
> >>Ciao,
> >>
> >>sto leggendo un po' di documentazione a proposito di PAE per le macchine 
> >>che hanno piu' di 4GB di memoria. Qualcuno mi puo' confermare che, per 
> >>una architettura Intel Xeon con piu' di 4GB di memoria, la quantita' 
> >>massima di memoria visibile da un processo è di 4GB e che solo il kernel 
> > 
> > no, la quantita' massima di memoria allocabile per un processo e' di 960
> > MB.
> > se il tuo programma ne necessita di piu' deve ricorrere a trucchetti di
> > vario tipo.
> > 
> > 
> >> si prende briga di gestire la memoria rimanente per assegnarla qua e 
> >>la' ai vari processi, oppure per il caching etc. ? E' implicito che su 
> >>'sto macchina girano simulazioni a cui piacerebbe tanto avere 1TB di 
> >>memoria disponibile ;-)
> > 
> > non e' implicito e, sostanzialmente, non si puo' fare in modo banale.
> > i modi corretti sono piu' d'uno, ma vanno attentamente valutati. mesi fa
> > c'e' stata una lunga discussione a riguardo nella mailing list del kernel,
> > prova a guardare li. Se non dovessi trovare nulla posso provare a dare un
> > occhio io.
> > 
> >>Grazie, Alfredo.
> > 
> > prego.
> > 
> > 
> >>P.S: il 18 dicembre è uscito il kernel 2.6.0 e nessuno ha detto nulla ?
> > 
> > che dire?
> > 

-- 



Maggiori informazioni sulla lista Lug