Come permettere a un processo di sfruttare più di 4Gb di RAM in Linux 32/64 bit?

[Scoperchiatore]

Come da oggetto.

Immaginate di avere un serverone con 16 GB di RAM, e un unico processo che occupa più di 4GB di RAM (potenzialmente arriva anche a tutti e 16 GB di RAM)

A prescindere sulle considerazioni riguardo il processo (che sappiate, ha un motivo per occupare così tanta RAM), vorrei capire la fattibilità di una cosa del genere su Linux rispetto anche all'architettura hardware su cui gira.

In un'architettura a 32 bit credo che questo NON si possa fare, perchè nonostante il PAE, il processore ha un limite fisico a indirizzare più di 4Gb di memoria (che poi diventano 3.2 Gb per lo split kernel space/user space)

HIGHMEM solution for using 64 GB of memory

This is enabled via the PAE (Physical Address Extension) extension of
the PentiumPro processors. PAE addresses the 4 GB physical memory
limitation and is seen as Intel's answer to AMD 64-bit and AMD x86-64.
PAE allows processors to access physical memory up to 64 GB (36 bits
of address bus). However, since the virtual address space is just 32
bits wide, each process can't grow beyond 4 GB. The mechanism used to
access memory from 4 GB to 64 GB is essentially the same as that of
accessing the 1 GB - 4 GB RAM via the HIGHMEM solution discussed
above.

A questo punto, basta avere un 64 bit e compilare il kernel con l'opzione HIGHMEM, per permettere a un processo di sguazzare liberamente nella RAM? Perchè il dubbio è che vi siano limiti architetturali nel kernel Linux che considerano una precondizione il fatto che un processo non indirizzerà mai più di 4 Gb!

Dalle mie ricerche, un 64 bit ha la capacità di dare a un processo un quantitativo di ram maggiore di 4 Gb, ma sinceramente sono ricerche fatte su google e quindi poco affidabili.

Però chiedo anche a voi, dato che la domanda nasce dalla necessità di acquistare un server abbastanza costoso, con parecchia RAM, da usare proprio per un processo RAM-ivoro di questo tipo. Se scoprissi, ad acquisto effettuato, che i soldi per comprare 16 Gb di RAM sono stati buttati per limiti software, ciò decretebbe severe pene per il sottoscritto :D

E comunque sia, è una curiosità che ho da tanto tempo, e che spero qualcuno sappia soddisfare definitivamente.

[Scoperchiatore]

uppettino.

Nessuno vuole dare il suo parere? :fagiano:

[ArtX]

hai detto bene
con un procio a 64-bit, l'os a 64-bit e l'opzione highmem del kernel le applicazioni possono sguazzare liberamente sulla ram con la sola limitazione dei 64-bit, guarda su wikipedia per vedere quali sono, ma ai giorni doggi penso siano insaziabili.
azz ma che cavolo di processo devi usare

[Scoperchiatore]

Confortante.

E' un processo che necessita di leggere tanti (15 Gb) dati, e ne tiene in memoria una considerevole parte. La sua occupazione di memoria dipende anche dalla size che si dà agli hash che usa, e arriva rapidissimamente a >4Gb se gli hash hanno larghezza >8.

Dato che sono hash deputati a contenere circa 80 elementi, la loro size ottimale sarebbe 32 o 64 (come potenze di due) e quindi è facile immaginare come mai mi serve così tanta RAM, per velocizzare il processo che ad oggi se la cava con 3 ore.

Un domani lo vorremmo allargare, e per far questo abbiamo bisogno di usare altra RAM. Ecco il perchè della domanda.

[ilsensine]

E' un processo che necessita di leggere tanti (15 Gb) dati, e ne tiene in memoria una considerevole parte.
Più che "ne tiene in memoria" (non è necessario (e neanche sufficiente!) "caricare" tutto un file con read() per "tenerlo in memoria"!) è semmai una questione di comodità, avere tanti indirizzi virtuali per poter indirizzare tutto il file. Con 32 bit puoi comunque "tenere in memoria" tutta quella roba, ma puoi mappare solo una parte del file di volta in volta.

[Scoperchiatore]

Più che "ne tiene in memoria" (non è necessario (e neanche sufficiente!) "caricare" tutto un file con read() per "tenerlo in memoria"!) è semmai una questione di comodità, avere tanti indirizzi virtuali per poter indirizzare tutto il file. Con 32 bit puoi comunque "tenere in memoria" tutta quella roba, ma puoi mappare solo una parte del file di volta in volta.

Il file viene letto riga per riga (proprio con read), ma le informazioni che sono lette devono essere strutturate per degli scopi.

In dettaglio stiamo parlando dell'evoluzione temporare di molte (circa 400) tabelle di routing, che devono essere "fuse" ed analizzate, e per le quali basta tenere traccia della best attuale.
Per mantenerla in memoria, usiamo hash a 2 livelli (sono necessari per quel che dobbiamo sapere), e nell'ultimo livello c'è una lista. 200.000 elementi nel primo livello x 100 elementi nel secondo x 50 caratteri (char) medi di una lista = 1000 Mb.
Considerando che questa è solo la lista massima, direi che rientriamo tranquillamente nelle dimensioni di cui sopra

In definitiva, i 2.8 Gb attualmente occupati con una versione dell'algoritmo che ha 2 bucket ad hash (ovvero, gli hash sono praticamente liste) sono più che giustificati, anche dai soli calcoli teorici. Teniamo presente che, in generale, un hash per essere tale, deve mantenere in memoria dei puntatori che sono overhead, in questo caso NON trascurabile, sulla RAM occupata. In generale, abbiamo calcolato 800 Mb di overhead...

Non ci possiamo svincolare da queste problematiche dato che la mole di dati da processare è talmente ampia (40 miliardi di righe) che l'algoritmo deve per forza avere complessità lineare.
Per permettere di mantenere la complessità lineare, si deve tener traccia dei risultati intermedi delle elaborazioni, e appena si riconosce un "cambio di stato", si scrive sui file di output e si sovrascrivono le vecchie info in memoria.

Vorrei evitare di installare una versione a 64 bit del sistema operativo, dato che di problemi ne ho avuti tanti, e questo tra l'altro dovrebbe essere un server su cui gira un servizio che sfrutta i dati calcolati da questo processo.

Tu mi confermi che un'architettura a 32 bit, pur con il PAE, non può dare ad un processo più di 4Gb (3.2 considerando lo split) di RAM?

[ilsensine]

Il file viene letto riga per riga (proprio con read), ma le informazioni che sono lette devono essere strutturate per degli scopi.

In dettaglio stiamo parlando dell'evoluzione temporare di molte (circa 400) tabelle di routing, che devono essere "fuse" ed analizzate, e per le quali basta tenere traccia della best attuale.
Per mantenerla in memoria, usiamo hash a 2 livelli (sono necessari per quel che dobbiamo sapere), e nell'ultimo livello c'è una lista. 200.000 elementi nel primo livello x 100 elementi nel secondo x 50 caratteri (char) medi di una lista = 1000 Mb.
Considerando che questa è solo la lista massima, direi che rientriamo tranquillamente nelle dimensioni di cui sopra

In definitiva, i 2.8 Gb attualmente occupati con una versione dell'algoritmo che ha 2 bucket ad hash (ovvero, gli hash sono praticamente liste) sono più che giustificati, anche dai soli calcoli teorici. Teniamo presente che, in generale, un hash per essere tale, deve mantenere in memoria dei puntatori che sono overhead, in questo caso NON trascurabile, sulla RAM occupata. In generale, abbiamo calcolato 800 Mb di overhead...

Non ci possiamo svincolare da queste problematiche dato che la mole di dati da processare è talmente ampia (40 miliardi di righe) che l'algoritmo deve per forza avere complessità lineare.
Per permettere di mantenere la complessità lineare, si deve tener traccia dei risultati intermedi delle elaborazioni, e appena si riconosce un "cambio di stato", si scrive sui file di output e si sovrascrivono le vecchie info in memoria.

Vorrei evitare di installare una versione a 64 bit del sistema operativo, dato che di problemi ne ho avuti tanti, e questo tra l'altro dovrebbe essere un server su cui gira un servizio che sfrutta i dati calcolati da questo processo.
Eh ma purtroppo da come descrivi una macchina a 64 bit sembra la cosa più adatta.

Tu mi confermi che un'architettura a 32 bit, pur con il PAE, non può dare ad un processo più di 4Gb (3.2 considerando lo split) di RAM?
Di indirizzi virtuali, non di ram. La ram è una cosa che il programmatore non deve sapere neanche che esiste.
Se proprio vuoi utilizzare macchine a 32 bit, puoi usare come "ram" un grosso file (open64 + ftrunc64 + unlink) -- può essere un file su fs "normale" (la page cache provvederà a tenerlo in ram a regime; fadvise ti viene in aiuto), o su tmpfs, o - meglio ancora - su hugetlbfs. tmpfs è memoria "anonima", dello stesso identico tipo che otterresti con malloc; hugetlbfs è simile al tmpfs ma utilizza huge pages invece di pagine di 4kb. Un pò più efficiente. In tutti e tre i casi puoi "allocare" ben più di 4 GB.
Il problema che devi affrontare è il seguente: deve essere compito tuo mappare (mmap64) di volta in volta, nello spazio di indirizzi del tuo programma, delle "finestre" del file/memoria su cui operare. In soldoni puoi ottenere la "memoria" che ti serve, anche con 32 bit, ma devi usare mmap per accedere a una certa regione -- non puoi "vedere" tutto il blocco in memoria contemporaneamente.
Si può fare, ma ha un overhead a causa delle mmap/munmap (dipendente da quante volte devi cambiare "finestra") e varie complicazioni non simpatiche.

[Scoperchiatore]

Di indirizzi virtuali, non di ram. La ram è una cosa che il programmatore non deve sapere neanche che esiste.
Se proprio vuoi utilizzare macchine a 32 bit, puoi usare come "ram" un grosso file (open64 + ftrunc64 + unlink) -- può essere un file su fs "normale" (la page cache provvederà a tenerlo in ram a regime; fadvise ti viene in aiuto), o su tmpfs, o - meglio ancora - su hugetlbfs. tmpfs è memoria "anonima", dello stesso identico tipo che otterresti con malloc; hugetlbfs è simile al tmpfs ma utilizza huge pages invece di pagine di 4kb. Un pò più efficiente. In tutti e tre i casi puoi "allocare" ben più di 4 GB.
Il problema che devi affrontare è il seguente: deve essere compito tuo mappare (mmap64) di volta in volta, nello spazio di indirizzi del tuo programma, delle "finestre" del file/memoria su cui operare. In soldoni puoi ottenere la "memoria" che ti serve, anche con 32 bit, ma devi usare mmap per accedere a una certa regione -- non puoi "vedere" tutto il blocco in memoria contemporaneamente.
Si può fare, ma ha un overhead a causa delle mmap/munmap (dipendente da quante volte devi cambiare "finestra") e varie complicazioni non simpatiche.

Devo fare un gestore di pagine sopra quello del sistema operativo :D.

Mi sembra una cosa abbastanza ardua, più che altro sovradimensionata per lo scopo (semmai la implementassi, sarebbe decisamente più interessante la struttura per gestire la memoria che il programma che la utilizza!)

A questo punto, direi che l'uso di un 64 bit è l'unica soluzione, speriamo che non crei problemi negli aggiornamenti (anche se una debian con i servizi base dovrebbe essere affidabile in tal senso)

Grazie dell'aiuto :)

[HexDEF6]

A questo punto, direi che l'uso di un 64 bit è l'unica soluzione, speriamo che non crei problemi negli aggiornamenti (anche se una debian con i servizi base dovrebbe essere affidabile in tal senso)

Grazie dell'aiuto :)


io ho una macchina biprocessore opteron con 12Gb e un cluster dove 14 nodi hanno 4 Gb....
mai avuto problemi con i 64 bit (mica ci devo andare su internet e usare i plugin flash!)
ovviamente montano tutti gentoo :D

Ciao

[Scoperchiatore]

io ho una macchina biprocessore opteron con 12Gb e un cluster dove 14 nodi hanno 4 Gb....
mai avuto problemi con i 64 bit (mica ci devo andare su internet e usare i plugin flash!)
ovviamente montano tutti gentoo :D

Ciao

Mmmmmh, caro amico mio, la tua testimonianza è musica per le mie orecchie! :cool:

Se mi dici che il tuo server (il mio sarà uno Xeon biprocessore, quindi stiamo lì) non ha mai avuto problemi con Gentoo + 64 bit, mi inviti a nozze, io sono un gentooista convinto e radicale :D

Scherzi a parte, essendo server da mettere su per applicazioni di ricerca, la potenza di uno strumento come portage ci sarebbe spesso utile (una cazzata: compilare gnuplot con tutte le opzioni che dico io, invece di usare un precompilato di cui mi devo andare a spulciare la doc per capire che plugin grafici ha), e quindi io sarei molto contento di installare gentoo (anche perchè c'è quel delta di ottimizzazione in più dovuta al compilato che non fa mai male)

Suppongo anche che un dual opteron ci metta poco a compilare cose come dbus o iptables, mentre magari impiega un quarto d'ora per gcc e glibc. Sbaglio?

Avresti qualche consiglio da darmi sulla compilazione del kernel? Devo stare attento a opzioni particolari, cerco guide sulla rete, oppure procedo come per le macchine desktop? (ovviamente con le dovute variazioni di periferiche e amenità varie)

[dennyv]

Avresti qualche consiglio da darmi sulla compilazione del kernel? Devo stare attento a opzioni particolari, cerco guide sulla rete, oppure procedo come per le macchine desktop? (ovviamente con le dovute variazioni di periferiche e amenità varie)

L'unico che mi viene in mente da parte mia è niente preemption e tieni il timer basso, 100Hz... eviti saturazione da interrupt.... per il resto tuning dei driver (niente amenità, suspend etc) ed è fatta!

Usa CFLAG non troppo spinte (direi un -O2 max, niente -O3 e -Os) per il resto...

In bocca al lupo!

[HexDEF6]

infatti... puoi andare tranquillo... i problemi dei 64 bit si hanno solo in ambito desktop (flash, openoffice, varie applicazioni proprietarie)...
lato server/calcolo i problemi sono pochi...
praticamente sulla macchina biprocessore opteron non ho mai avuto nessun problema, ne ho avuto qualcuno sulle macchine del cluster, che sono degli athlon 64 X2 4400 su scheda madre asus con nforce4...
ma erano problemi dei primi bios delle schede madri (questo perche' le schede madri per desktop, supportano si i 64 bit, ma in verita' vedono al massimo 4 Gb, e se li hai tutti occupati dalla ram le periferiche pci non "sanno dove ficcarsi" e all'inizio quindi venivano visti solo 3 Gb o c'erano rogne con corruzioni di dati su disco o via rete... ma come gia detto, risolto tutto con aggiornamento del bios e un settaggio nello stesso... e per sicurezza ho passato al kernel iommu=force)

Ciao!

[Scoperchiatore]

Ottimo, grazie mille per le informazioni!

Speriamo di non fare danni :D