Processi e Memoria in HP-UX

[fpucci]

Spero di avere qualche delucidazione in merito.

Supponiamo di avere N-processi applicativi che girano contemporaneamente (oltre a quelli di sistema).

Poiché ogni processo ha uno spazio di 4Gb di indirizzi virtuali (configurabili nel kernel) che può indirizzare, (di cui 1 per il codice, 1Gb per i dati, 1Gb per gli oggetti condivisi (libreria, memoria), ed un altro Gb di indirizzi per l'I/O), cosa succede quando sia la memoria di sistema che quella virtuale stanno per finire?

Ovvero, se faccio partire altri procesi e quelli già presenti non sfruttano tutti i 4Gb a loro riservati, il sistema assegna la memoria non utilizzata dai processi già attivi e la assegna ai nuovi processi in partenza (diminuendo la memoria disponibile per cisacun processo) oppure si comporta diversamente?
Come si comporterebbe?

Il sistema in questione è una macchina HP 9000/800 con HP-UX B.11.11

[ilsensine]

Non conosco quella architettura, ma normalmente ciascun processo dispone di una propria regione di 4 GB di indirizzi virtuali, indipendente dagli altri processi. Sotto linux solo 3 sono effettivamente utilizzabili dall'applicazione.
Questo è vero solo per architetture a 32 bit ovviamente,

[fpucci]

Originariamente inviato da ilsensine
Non conosco quella architettura, ma normalmente ciascun processo dispone di una propria regione di 4 GB di indirizzi virtuali, indipendente dagli altri processi. [...]

Certo, ma cosa succede a questa quota di 4Gb quando la memoria sta per finire? Rimane sempre quel valore oppure potrebbe diminuire per permettere fi dar nascere altri processi?

Questo è vero solo per architetture a 32 bit ovviamente,

Si, si parla di architeture a 32 bit ovviamente, con spazi di indirizzamento a 4Gb

[Scoperchiatore]

Originariamente inviato da fpucci
Certo, ma cosa succede a questa quota di 4Gb quando la memoria sta per finire? Rimane sempre quel valore oppure potrebbe diminuire per permettere fi dar nascere altri processi?


Si, si parla di architeture a 32 bit ovviamente, con spazi di indirizzamento a 4Gb

No, si dice che il sistema va in trashing e non permette il nascere di nuovi processi. Contemporaneamente uccide quelli non kernel che allocano nuova memoria.

E' un problema che su Win mi si è verificato un paio di volte, soprattutto con un paging ristretto e una CPU non velocissima. E' praticamente impossibile lavorare....
Anzi, no, NT regge bene quando trasha

[ilsensine]

Originariamente inviato da fpucci
Certo, ma cosa succede a questa quota di 4Gb quando la memoria sta per finire? Rimane sempre quel valore oppure potrebbe diminuire per permettere fi dar nascere altri processi?

Il problema è molto più complesso di quanto credi. Posso parlare per linux, ma credo che per altri s/o il discorso è simile.
Non confondere _mai_ memoria virtuale e memoria fisica. La memoria virtuale è soltanto un insieme (contenitore) di pagine virtuali, dove il sistema operativo può mappare, come e quando ritiene opportuno, alcune pagine. In particolare una pagina virtuale può contenere:
1) Niente: Ti sembrerà strano, ma è il caso più frequente. Quando accedi alla pagina viene generata una eccezione, in corrispondenza della quale il kernel mappa "fisicamente" la pagina richiesta. La pagina può essere di uno dei tipi descritti sotto, oppure può essere una pagina finita in swap, oppure una pagina COW (copy(create)-on-write). Se nessuna pagina può essere recuperata (ad es. in condizioni gravi di OOM), si attiva l'OOM killer che si occupa di uccidere il processo che ha generato l'eccezione, oppure altri processi per soddisfare la richiesta di memoria. Il funzionamento dell'OOM killer è quanto di più problematico ci sia da gestire.
2) Memoria fisica. Sotto pressione di memoria, la pagina fisica può essere spedita in swap e si ritorna al caso 1). Linux utilizza spesso ottimizzazioni particolari dove una pagina è sia in swap che in memoria, in modo da poter liberare memoria fisica velocemente quando richiesto, avendo già effettuato lo swapout in condizioni di carico meno critiche.
3) Un file: in questo caso le pagine mappate provengono dalla page cache del sistema operativo, e sono comuni (condivise) tra tutti i processi che mappano il file. La page cache può essere ridotta o espansa secondo le situazioni di carico, riscrivendole o recuperandole dal file. Le pagine del file che non sono correntemente in page cache rientrano nel caso 1).
4) Memoria condivisa tra più programmi. Può essere gestita come in 2), con la particolarità che la pagina fisica è unica per tutte le applicazioni che la utilizzano. Esistono casi particolari di condivisione, gestiti in mamiera molto efficiente tramite le tecniche COW; la funzione fork() è il principale utilizzatore del COW.
5) Memoria di i/o: tecnica utilizzata ad es. da xfree per accedere ai registri delle schede video. Nessuna pagina della memoria di sistema sarà mai associata alla mappatura virtuale, che per contro finirà direttamente sulla iomem di un dispositivo.
6) mmap di un dispositivo: il suo significato effettivo dipende dal dispositivo. Alcune volte è analoga al caso 5), ma spesso è qualcosa di diverso.

Come vedi, non è facile stabilire "quando la memoria sta per finire" solamente guardando la mappatura virtuale dei processi. E' frequente il caso in cui un processo utilizza una libreria, che viene mappata come un file, ma della quale utilizza solo poche pagine: il "grosso" della libreria risulterebbe comunque mappato (e disponibile all'applicazione in caso di necessità), ma le pagine virtuali non corrisponderebbero a nessuna pagina fisica e così rimarranno probabilmente fino al termine dell'applicazione.

[fpucci]

Originariamente inviato da ilsensine
Come vedi, non è facile stabilire "quando la memoria sta per finire" solamente guardando la mappatura virtuale dei processi. E' frequente il caso in cui un processo utilizza una libreria, che viene mappata come un file, ma della quale utilizza solo poche pagine: il "grosso" della libreria risulterebbe comunque mappato (e disponibile all'applicazione in caso di necessità), ma le pagine virtuali non corrisponderebbero a nessuna pagina fisica e così rimarranno probabilmente fino al termine dell'applicazione.

Grazie per la spiegazione.
Purtroppo il problema è che a me va in errore un tentativo di riallocazione di un'area di memoria [realloc()] di 2Mb con un messaggio di errore "Not enought memory..."!

Stavo pensando di mettere le mani su uno dei parametri del kernel (credo che sia uno di quelli che vengono gestiti anche dalla setrlimit()) ma non saprei proprio se sia la strada giusta... e quale sia la strada giusta...

[ilsensine]

Originariamente inviato da fpucci
Grazie per la spiegazione.
Purtroppo il problema è che a me va in errore un tentativo di riallocazione di un'area di memoria [realloc()] di 2Mb con un messaggio di errore "Not enought memory..."!

Questo può accadere per più motivi:
- hai esaurito gli indirizzi virtuali per il tuo processo
- hai esaurito la quota di memoria per il tuo processo (settabile tramite il comando ulimit)
- hai frammentato troppo l'heap e non riesci a trovare 2 MB di indirizzi virtuali contigui
Sono tutti casi improbabili, a meno che non hai qualche serio memory leak nel programma o allochi una quantità di memoria veramente enorme

Stavo pensando di mettere le mani su uno dei parametri del kernel (credo che sia uno di quelli che vengono gestiti anche dalla setrlimit()) ma non saprei proprio se sia la strada giusta... e quale sia la strada giusta...

Se è un problema di quote per il processo puoi verificarlo facilmente maneggiando con il comando ulimit, prima di eseguire il programma. Occhio che innalzare gli hard limit richiede i privilegi di root.