Torna indietro   Hardware Upgrade Forum > Software > Linux, Unix, OS alternativi

Lenovo ThinkPad X1 2-in-1 G10 Aura Edition: il convertibile di classe
Lenovo ThinkPad X1 2-in-1 G10 Aura Edition: il convertibile di classe
La flessibilità di configurazione è il punto di forza di questo 2-in-1, che ripropone in un form factor alternativo tutta la tipica qualità dei prodotti Lenovo della famiglia ThinkPad. Qualità costruttiva ai vertici, ottima dotazione hardware ma costo che si presenta molto elevato.
Intervista a Stop Killing Games: distruggere videogiochi è come bruciare la musica di Mozart
Intervista a Stop Killing Games: distruggere videogiochi è come bruciare la musica di Mozart
Mentre Ubisoft vorrebbe chiedere agli utenti, all'occorrenza, di distruggere perfino le copie fisiche dei propri giochi, il movimento Stop Killing Games si sta battendo per preservare quella che l'Unione Europea ha già riconosciuto come una forma d'arte. Abbiamo avuto modo di parlare con Daniel Ondruska, portavoce dell'Iniziativa Europa volta a preservare la conservazione dei videogiochi
Samsung Galaxy S25 Edge: il top di gamma ultrasottile e leggerissimo. La recensione
Samsung Galaxy S25 Edge: il top di gamma ultrasottile e leggerissimo. La recensione
Abbiamo provato il nuovo Galaxy S25 Edge, uno smartphone unico per il suo spessore di soli 5,8 mm e un peso super piuma. Parliamo di un device che ha pro e contro, ma sicuramente si differenzia dalla massa per la sua portabilità, ma non senza qualche compromesso. Ecco la nostra prova completa.
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 02-03-2007, 16:49   #1
Scoperchiatore
Senior Member
 
L'Avatar di Scoperchiatore
 
Iscritto dal: Sep 2001
Città: Roma
Messaggi: 1944
Come permettere a un processo di sfruttare più di 4Gb di RAM in Linux 32/64 bit?

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)

Quote:
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

E comunque sia, è una curiosità che ho da tanto tempo, e che spero qualcuno sappia soddisfare definitivamente.
__________________
"Oggi è una di quelle giornate in cui il sole sorge veramente per umiliarti" Chuck Palahniuk

Io c'ero
Scoperchiatore è offline   Rispondi citando il messaggio o parte di esso
Old 04-03-2007, 15:20   #2
Scoperchiatore
Senior Member
 
L'Avatar di Scoperchiatore
 
Iscritto dal: Sep 2001
Città: Roma
Messaggi: 1944
uppettino.

Nessuno vuole dare il suo parere?
__________________
"Oggi è una di quelle giornate in cui il sole sorge veramente per umiliarti" Chuck Palahniuk

Io c'ero
Scoperchiatore è offline   Rispondi citando il messaggio o parte di esso
Old 04-03-2007, 15:35   #3
ArtX
Registered User
 
Iscritto dal: Feb 2005
Messaggi: 1856
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
ArtX è offline   Rispondi citando il messaggio o parte di esso
Old 05-03-2007, 13:37   #4
Scoperchiatore
Senior Member
 
L'Avatar di Scoperchiatore
 
Iscritto dal: Sep 2001
Città: Roma
Messaggi: 1944
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.
__________________
"Oggi è una di quelle giornate in cui il sole sorge veramente per umiliarti" Chuck Palahniuk

Io c'ero
Scoperchiatore è offline   Rispondi citando il messaggio o parte di esso
Old 05-03-2007, 13:45   #5
ilsensine
Senior Member
 
L'Avatar di ilsensine
 
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
Quote:
Originariamente inviato da Scoperchiatore Guarda i messaggi
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.
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al
andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12
ilsensine è offline   Rispondi citando il messaggio o parte di esso
Old 05-03-2007, 14:27   #6
Scoperchiatore
Senior Member
 
L'Avatar di Scoperchiatore
 
Iscritto dal: Sep 2001
Città: Roma
Messaggi: 1944
Quote:
Originariamente inviato da ilsensine Guarda i messaggi
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?
__________________
"Oggi è una di quelle giornate in cui il sole sorge veramente per umiliarti" Chuck Palahniuk

Io c'ero
Scoperchiatore è offline   Rispondi citando il messaggio o parte di esso
Old 05-03-2007, 14:46   #7
ilsensine
Senior Member
 
L'Avatar di ilsensine
 
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
Quote:
Originariamente inviato da Scoperchiatore Guarda i messaggi
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.

Quote:
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.
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al
andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12

Ultima modifica di ilsensine : 05-03-2007 alle 14:49.
ilsensine è offline   Rispondi citando il messaggio o parte di esso
Old 05-03-2007, 19:55   #8
Scoperchiatore
Senior Member
 
L'Avatar di Scoperchiatore
 
Iscritto dal: Sep 2001
Città: Roma
Messaggi: 1944
Quote:
Originariamente inviato da ilsensine Guarda i messaggi
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 .

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
__________________
"Oggi è una di quelle giornate in cui il sole sorge veramente per umiliarti" Chuck Palahniuk

Io c'ero
Scoperchiatore è offline   Rispondi citando il messaggio o parte di esso
Old 05-03-2007, 22:08   #9
HexDEF6
Senior Member
 
L'Avatar di HexDEF6
 
Iscritto dal: Dec 2000
Città: Trento
Messaggi: 5917
Quote:
Originariamente inviato da Scoperchiatore Guarda i messaggi
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

Ciao
__________________
Linux User #272700 >+++++++++[<+++++++++>-]<+.++.>++++[<---->-]<++.+++++++.
HOWTO: SSH Firewall e DMZ
ɐɹdosoʇʇos oʇuǝs ıɯ
HexDEF6 è offline   Rispondi citando il messaggio o parte di esso
Old 06-03-2007, 11:10   #10
Scoperchiatore
Senior Member
 
L'Avatar di Scoperchiatore
 
Iscritto dal: Sep 2001
Città: Roma
Messaggi: 1944
Quote:
Originariamente inviato da HexDEF6 Guarda i messaggi
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

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

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

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)
__________________
"Oggi è una di quelle giornate in cui il sole sorge veramente per umiliarti" Chuck Palahniuk

Io c'ero
Scoperchiatore è offline   Rispondi citando il messaggio o parte di esso
Old 06-03-2007, 13:05   #11
dennyv
Senior Member
 
L'Avatar di dennyv
 
Iscritto dal: Sep 2003
Città: Bergamo
Messaggi: 1176
Quote:
Originariamente inviato da Scoperchiatore Guarda i messaggi
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!
__________________
VGA? No grazie, preferisco le SERIALI!
http://daniele.vigano.me | Home server HP Proliant MicroServer (Fedora 64bit) | Notebook Dell Latitude E5450 (Fedora 64bit) | Mobile Moto G3
GEM HPC Cluster Dell PowerEdge R720xd + R720 + R420 + M1000e + M915 (Ubuntu LTS 64bit) up to 1000 cores | EATON UPS
dennyv è offline   Rispondi citando il messaggio o parte di esso
Old 06-03-2007, 14:50   #12
HexDEF6
Senior Member
 
L'Avatar di HexDEF6
 
Iscritto dal: Dec 2000
Città: Trento
Messaggi: 5917
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!
__________________
Linux User #272700 >+++++++++[<+++++++++>-]<+.++.>++++[<---->-]<++.+++++++.
HOWTO: SSH Firewall e DMZ
ɐɹdosoʇʇos oʇuǝs ıɯ
HexDEF6 è offline   Rispondi citando il messaggio o parte di esso
Old 06-03-2007, 16:10   #13
Scoperchiatore
Senior Member
 
L'Avatar di Scoperchiatore
 
Iscritto dal: Sep 2001
Città: Roma
Messaggi: 1944
Ottimo, grazie mille per le informazioni!

Speriamo di non fare danni
__________________
"Oggi è una di quelle giornate in cui il sole sorge veramente per umiliarti" Chuck Palahniuk

Io c'ero
Scoperchiatore è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Lenovo ThinkPad X1 2-in-1 G10 Aura Edition: il convertibile di classe Lenovo ThinkPad X1 2-in-1 G10 Aura Edition: il c...
Intervista a Stop Killing Games: distruggere videogiochi è come bruciare la musica di Mozart Intervista a Stop Killing Games: distruggere vid...
Samsung Galaxy S25 Edge: il top di gamma ultrasottile e leggerissimo. La recensione Samsung Galaxy S25 Edge: il top di gamma ultraso...
HP Elitebook Ultra G1i 14 è il notebook compatto, potente e robusto HP Elitebook Ultra G1i 14 è il notebook c...
Microsoft Surface Pro 12 è il 2 in 1 più compatto e silenzioso Microsoft Surface Pro 12 è il 2 in 1 pi&u...
La Cina ha sviluppato una macchina in gr...
Lanciati cinque nuovi satelliti cinesi G...
Meta avrebbe scaricato illegalmente migl...
QNAP annuncia la funzionalità di ...
Fino a 96 core per chip: la nuova CPU se...
Robot che crescono mangiando i loro simi...
Star Wars Outlaws 2 cancellato: per Ubis...
F1 senza freni: il film supera i 500 mil...
Una supersportiva elettrica da 429 CV a ...
Denodo DeepQuery: ricerche complesse in ...
Pluribus è la nuova ambiziosa ser...
IA come persone: avranno una personalit&...
Scoppia la bufera NSFW: la mano di Colle...
Philips porta OneBlade su Fortnite: arri...
Il consumo dei data center AI esplode: r...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 20:47.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Served by www3v