Να βάλω 32bit ή 64bit πυρήνα; η απάντηση από τον Linus Torvalds

[DIMITRISG]

Πολλές φορές τίθεται το ερώτημα αν πρέπει να βάλουμε 32bit ή 64bit πυρήνα.

Ο Linus Torvalds απάντησε έμεσα σε αυτό το ερώτημα :

 

The biggest single reason to go 64-bit is exactly

because of physical address space. Your virtual address

space needs to bea multiple of the physical one:

when you hit 1GB of RAM, 32-bit virtual memory is no longer

acceptable. You literally do need more virtual memory than

physical.

 

http://www.realworldtech.com/forums/index.cfm?action=detail&id=78966&threadid=78766&roomid=2

 

Με ικανοποίησε η απάντηση ή μάλλον η επεξήγηση γιατί δεν περιορίζεται στο συνηθισμένο: «Τι επεξεργαστή έχεις;»

[Hlapatsas]

Όποιος κατέχει την γνώση παρακαλείται να μας το εξηγήσει με δύο απλά λόγια, είναι ενδιαφέρον θέμα πιστεύω.

[NullScan]

Επειδή το θέμα είναι μεγάλο θα δώσω μιά μικρή εξήγηση και μέσω ερωτήσεων μπορούμε να επεκταθούμε αν υπάρχει ανταπόκριση.

Λέω από την αρχή ότι ΔΕΝ είμαι σε καμία περίπτωση ειδήμονας πάνω στο θέμα και τα περισσότερα από τα παρακάτω είναι πιό πολύ από θεωρία και λιγότερο από εμπειρία.

Έστω ολόκληρη η μνήμη (RAM) ενός συστήματος. Για αρχή, θα το συζητήσουμε για 4GB μνήμη

 

Το νούμερο δέν είναι τυχαίο, και όπως οι περισσότεροι θα γνωρίζετε αυτό είναι και (κοντά) στο όριο της max μνήμης που μπορεί να διαχειριστεί ένα32-bit OS χωρίς Physical Address Extension (PAE). 2^32 = 4294967296 bytes = 4 Gb

 

Ένα process όταν εκτελείται και ζητάει RAM από το λειτουργικό για να εκτελεστεί, δέν θα πρέπει να το ενδιαφέρει σε ποιό μέσο θα αποθηκευτούν τα data που έχει να αποθηκεύσει στη μνήμη, είτε στην physical memory είτε στο swap. Το σύνολο της μνήμης που χρειάζεται ένα application για να αποθηκεύσει ΟΛΑ τα δεδομένα του στη μνήμη, machine code + data space + IO buffers και οτιδήποτε άλλο χρειάζεται, ονομάζεται Physical Memory. Κάπως έτσι δούλευαν τα παλιότερα λειτουργικά γι αυτό και η αναφορά του Torvalds σε highmem.sys όπου για να εκτελεστούν μεγάλες εφαρμογές σε παλιότερα λειτουργικά, έπρεπε να κάνεις offload κάποια από τα δεδομένα της μνήμης στη high memory (protected adress space, μεγάλη κουβέντα και αυτό) για να γίνει χώρος στη low memory ώστε να φορτωθεί η μεγάλη εφαρμογή. Τα σύγχρονα λειτουργικά για λόγους που σχετίζονται με το multitasking και την πιό γρήγορη πρόσβαση των εφαρμογών στα δεδομένα ΤΟΥΣ που είναι ανά πάσα στιγμή στη μνήμη, δέν δίνουν στις εφαρμογές που ξεκινάνε όλη αυτή τη μνήμη αλλά ψάχνουν να βρούν με πόση λίγη μνήμη μπορεί η εφαρμογή να εκτελεστεί κανονικά και του δίνουν αυτό το ποσό μνήμης. Αυτό λέγεται Virtual Memory.

Θα ρωτήσει κανένας, "καλά και πού είναι τα υπόλοιπα δεδομένα που χρειάζεται η εφαρμογή?". Η σύντομη απάντηση είναι πουθενά. Τα φορτώνει το λειτουργικό τη στιγμή που θα τα χρειαστεί το application στη Virtual memory για την κάθε εφαρμογή. Αυτό σημαίνει προφανώς οτι η virtual memory δέν έχει σταθερό μέγεθος και πρέπει ανά πάσα στιγμή να μπορεί να αυξηθεί ή να μειωθεί και γι αυτό η αναφορά του Torvalds για memory mapping και remapping, μιά πολύ αργή και επίπονη διαδικασία ειδικά όταν η virtual memory ενός application έχει γίνει τόσο fragmented από τις πολλές αλλαγές που το λειτουργικό την έχει "απλώσει" σε πάρα πολλά σημεία της RAM. Πρέπει να κρατάει pointers από το ένα κομμάτι στο άλλο και όταν η εφαρμογή ζητήσει data από τη μνήμη ο kernel θα πρέπει να πηγαίνει από address space σε address space μέχρι να τη βρεί. Και όπως ακριβώς και στους δίσκους, το fragmentation προκαλεί εκτός από χαμηλό response time και πολύ αυξημένες πιθανότητες για data corruption.

Όσο για το θέμα του PAE που κράζει ο Torvalds, έχει ένα δίκιο αλλά οχι απόλυτο. Το PAE είναι μιά hack-ιά ακόμα για να μπορέσουν 32-bit λειτουργικά να δούνε και να διαχειριστούν RAM μεγαλύτερη των 4Gb. Ο τρόπος που το κάνουν αυτό είναι αρκετά απλός, με μιά ειδική διαδικασία, αλλάζει το mapping της RAM από 32bit σε 32+4 = 36, 2^36=64Gb. Δέν θα αναλύσω τον τρόπο που γίνεται αυτό αλλά το αποτέλεσμα αυτής της μαϊμουδιάς είναι οτι το λειτουργικό παρότι πλέον βλέπει και μπορεί να διαχειριστεί περισσότερη μνήμη, ο περιορισμός που υπάρχει στα 32-bit λειτουργικά που λέει οτι ο kernel μπορεί να πάρει μέχρι 1Gb μνήμης και οι υπόλοιπες εφαρμογές μέχρι 3, δέν αλλάζει. Δηλαδή ακόμα και αν έχει κάποιος 64Gb σε 32-bit + PAE λειτουργικό, ουσιαστικά ο kernel δέν μπορεί να διαχειριστεί πάνω από 3Gb από αυτά τα data και εκεί γίνονται διάφοροι χειρισμοί για να μήν χάνονται τα data που δέν είναι "διαχειρίσιμα" πέραν των 3Gb δηλαδή. Βέβαια αυτό σημαίνει οτι ο kernel έχει να κάνει και extra δουλειά γιατί εκτός από τα προηγούμενα που λέγαμε για fragmentation και μετάβαση από ένα σημείο του adress space στο άλλο για την ίδια εφαρμογή, πρέπει να μπορεί να πάει και στην extra μνήμη, εκτός του ορίου των 3Gb (για εφαρμογές) άρα έχει περισσότερους memory pointers να διαχειριστεί.

Εν κατακλείδι, αυτό που λέει ο Torvalds είναι οτι αυτό το minimum σε RAM που κάνει assign ο kernel ανά process για να εκτελεστεί αυτή, πρέπει να είναι ΤΟΥΛΑΧΙΣΤΟΝ διπλάσια από αυτή που χρειάζεται η εφαρμογή για να εκτελεστεί για να επιτρέπονται τα remappings στο ίδιο address space χωρίς πολλά jumps και χωρίς fragmentation. Αυτό δέν γίνεται χωρίς 64-bit kernel (και hardware φυσικά) γιατί απλώς δέν υπάρχει πρόβλεψη για διαχείριση τόσο μεγάλων αποθηκευτικών μέσων σε 32bit.

Δέν έχω καμία ιδέα αν βγαίνει άκρη από όλα αυτά, ακούω ερωτήσεις ή/και παρατηρήσεις για διορθώσεις. Μετά τον πρωινό καφέ όμως

[egw_eimai_re]

Πιστεύω είσαι σωστά διαβασμένος

[NullScan]

Χαχαχ, εντάξει μέσες άκρες γιατί 1ον χωρίς καφέ το μυαλό δέ δουλεύει και 2ον δέ βλέπω και μεγάλη ανταπόκριση, είναι και δύστροπο το θέμα να το εξηγήσεις σε 5 αράδες...

[firewalker]

Επειδή το θέμα είναι μεγάλο θα δώσω μιά μικρή εξήγηση και μέσω ερωτήσεων μπορούμε να επεκταθούμε αν υπάρχει ανταπόκριση.

Λέω από την αρχή ότι ΔΕΝ είμαι σε καμία περίπτωση ειδήμονας πάνω στο θέμα και τα περισσότερα από τα παρακάτω είναι πιό πολύ από θεωρία και λιγότερο από εμπειρία.

Έστω ολόκληρη η μνήμη (RAM) ενός συστήματος. Για αρχή, θα το συζητήσουμε για 4GB μνήμη

 

Το νούμερο δέν είναι τυχαίο, και όπως οι περισσότεροι θα γνωρίζετε αυτό είναι και (κοντά) στο όριο της max μνήμης που μπορεί να διαχειριστεί ένα32-bit OS χωρίς Physical Address Extension (PAE). 2^32 = 4294967296 bytes = 4 Gb

 

Ένα process όταν εκτελείται και ζητάει RAM από το λειτουργικό για να εκτελεστεί, δέν θα πρέπει να το ενδιαφέρει σε ποιό μέσο θα αποθηκευτούν τα data που έχει να αποθηκεύσει στη μνήμη, είτε στην physical memory είτε στο swap. Το σύνολο της μνήμης που χρειάζεται ένα application για να αποθηκεύσει ΟΛΑ τα δεδομένα του στη μνήμη, machine code + data space + IO buffers και οτιδήποτε άλλο χρειάζεται, ονομάζεται Physical Memory. Κάπως έτσι δούλευαν τα παλιότερα λειτουργικά γι αυτό και η αναφορά του Torvalds σε highmem.sys όπου για να εκτελεστούν μεγάλες εφαρμογές σε παλιότερα λειτουργικά, έπρεπε να κάνεις offload κάποια από τα δεδομένα της μνήμης στη high memory (protected adress space, μεγάλη κουβέντα και αυτό) για να γίνει χώρος στη low memory ώστε να φορτωθεί η μεγάλη εφαρμογή. Τα σύγχρονα λειτουργικά για λόγους που σχετίζονται με το multitasking και την πιό γρήγορη πρόσβαση των εφαρμογών στα δεδομένα ΤΟΥΣ που είναι ανά πάσα στιγμή στη μνήμη, δέν δίνουν στις εφαρμογές που ξεκινάνε όλη αυτή τη μνήμη αλλά ψάχνουν να βρούν με πόση λίγη μνήμη μπορεί η εφαρμογή να εκτελεστεί κανονικά και του δίνουν αυτό το ποσό μνήμης. Αυτό λέγεται Virtual Memory.

Θα ρωτήσει κανένας, "καλά και πού είναι τα υπόλοιπα δεδομένα που χρειάζεται η εφαρμογή?". Η σύντομη απάντηση είναι πουθενά. Τα φορτώνει το λειτουργικό τη στιγμή που θα τα χρειαστεί το application στη Virtual memory για την κάθε εφαρμογή. Αυτό σημαίνει προφανώς οτι η virtual memory δέν έχει σταθερό μέγεθος και πρέπει ανά πάσα στιγμή να μπορεί να αυξηθεί ή να μειωθεί και γι αυτό η αναφορά του Torvalds για memory mapping και remapping, μιά πολύ αργή και επίπονη διαδικασία ειδικά όταν η virtual memory ενός application έχει γίνει τόσο fragmented από τις πολλές αλλαγές που το λειτουργικό την έχει "απλώσει" σε πάρα πολλά σημεία της RAM. Πρέπει να κρατάει pointers από το ένα κομμάτι στο άλλο και όταν η εφαρμογή ζητήσει data από τη μνήμη ο kernel θα πρέπει να πηγαίνει από address space σε address space μέχρι να τη βρεί. Και όπως ακριβώς και στους δίσκους, το fragmentation προκαλεί εκτός από χαμηλό response time και πολύ αυξημένες πιθανότητες για data corruption.

Όσο για το θέμα του PAE που κράζει ο Torvalds, έχει ένα δίκιο αλλά οχι απόλυτο. Το PAE είναι μιά hack-ιά ακόμα για να μπορέσουν 32-bit λειτουργικά να δούνε και να διαχειριστούν RAM μεγαλύτερη των 4Gb. Ο τρόπος που το κάνουν αυτό είναι αρκετά απλός, με μιά ειδική διαδικασία, αλλάζει το mapping της RAM από 32bit σε 32+4 = 36, 2^36=64Gb. Δέν θα αναλύσω τον τρόπο που γίνεται αυτό αλλά το αποτέλεσμα αυτής της μαϊμουδιάς είναι οτι το λειτουργικό παρότι πλέον βλέπει και μπορεί να διαχειριστεί περισσότερη μνήμη, ο περιορισμός που υπάρχει στα 32-bit λειτουργικά που λέει οτι ο kernel μπορεί να πάρει μέχρι 1Gb μνήμης και οι υπόλοιπες εφαρμογές μέχρι 3, δέν αλλάζει. Δηλαδή ακόμα και αν έχει κάποιος 64Gb σε 32-bit + PAE λειτουργικό, ουσιαστικά ο kernel δέν μπορεί να διαχειριστεί πάνω από 3Gb από αυτά τα data και εκεί γίνονται διάφοροι χειρισμοί για να μήν χάνονται τα data που δέν είναι "διαχειρίσιμα" πέραν των 3Gb δηλαδή. Βέβαια αυτό σημαίνει οτι ο kernel έχει να κάνει και extra δουλειά γιατί εκτός από τα προηγούμενα που λέγαμε για fragmentation και μετάβαση από ένα σημείο του adress space στο άλλο για την ίδια εφαρμογή, πρέπει να μπορεί να πάει και στην extra μνήμη, εκτός του ορίου των 3Gb (για εφαρμογές) άρα έχει περισσότερους memory pointers να διαχειριστεί.

Εν κατακλείδι, αυτό που λέει ο Torvalds είναι οτι αυτό το minimum σε RAM που κάνει assign ο kernel ανά process για να εκτελεστεί αυτή, πρέπει να είναι ΤΟΥΛΑΧΙΣΤΟΝ διπλάσια από αυτή που χρειάζεται η εφαρμογή για να εκτελεστεί για να επιτρέπονται τα remappings στο ίδιο address space χωρίς πολλά jumps και χωρίς fragmentation. Αυτό δέν γίνεται χωρίς 64-bit kernel (και hardware φυσικά) γιατί απλώς δέν υπάρχει πρόβλεψη για διαχείριση τόσο μεγάλων αποθηκευτικών μέσων σε 32bit.

Δέν έχω καμία ιδέα αν βγαίνει άκρη από όλα αυτά, ακούω ερωτήσεις ή/και παρατηρήσεις για διορθώσεις. Μετά τον πρωινό καφέ όμως

 

respect.

 

 

/me κάνει μικρά πολύ μικρά κομματάκια τα data του NullScan και του αλλάζει τους pointers.

[martinoff]

ένα και ένα τα μηνύματα του NullScan

εγώ δεν καταλαβαίνω γιατί πρέπει να υπάρχει ακόμα αυτό το δίλημμα, δεν είναι πλέων ποιο ελαφριά τα 32bit OS, γιατί αυτός είναι ο κυριότερος λόγος και αυτό ποιο πολύ στα win όχι τόσο στο linux

[NullScan]

/me κάνει μικρά πολύ μικρά κομματάκια τα data του NullScan και του αλλάζει τους pointers.

 

Ε μη το virtual address space μου λέμε!!!! είναι ευαίσθητο

BTW, martinoff δέν νομίζω οτι τέθηκε ποτέ θέμα απαιτήσεων για 64bit OS, δέν μπορώ να σκεφτώ κάποιο λόγο για να είναι πιό βαρύ. Απλώς υπάρχουν (υπήρχαν) θέματα συμβατότητας σε πολλά επίπεδα...

[mandos]

Thnx nullscan, δεν έχω τις βάσεις για να το καταλάβω πλήρως αλλά σίγουρα έπιασα πολλά από όσα έγραψες, όπως πάντα

[imitheos]

Ε μη το virtual address space μου λέμε!!!! είναι ευαίσθητο

BTW, martinoff δέν νομίζω οτι τέθηκε ποτέ θέμα απαιτήσεων για 64bit OS, δέν μπορώ να σκεφτώ κάποιο λόγο για να είναι πιό βαρύ. Απλώς υπάρχουν (υπήρχαν) θέματα συμβατότητας σε πολλά επίπεδα...

 

Το binary θα έχει μεγαλύτερο μέγεθος και επίσης έχει μεγαλύτερο "memory footprint". Ας υποθέσουμε ότι το πρόγραμμά σου έχει ένα πίνακα από 1000 στοιχεία. Σε 64bit θα θέλει διπλή μνήμη. Αυτό εννοείται συνήθως όταν λέγεται ότι το 64bit είναι πιο βαρύ.

 

Με τα σημερινά μεγέθη μνήμης και σκληρών και τα δύο επιχειρήματα είναι χαζά

 

Έστω ολόκληρη η μνήμη (RAM) ενός συστήματος. Για αρχή, θα το συζητήσουμε για 4GB μνήμη

 

Το νούμερο δέν είναι τυχαίο, και όπως οι περισσότεροι θα γνωρίζετε αυτό είναι και (κοντά) στο όριο της max μνήμης που μπορεί να διαχειριστεί ένα32-bit OS χωρίς Physical Address Extension (PAE). 2^32 = 4294967296 bytes = 4 Gb

 

 

Επίσης 4GB * 4Kb block size που έχουν τα περισσότερα filesystems μας δίνει 16TB. Αυτό σημαίνει ότι δεν μπορούμε να προσπελάσουμε > 16TB αποθηκευτικό χώρο. Βέβαια 16TB δεν είναι κάτι που έχει ο καθένας σπίτι του αλλά με τους 2TB και 3TB δίσκους που κυκλοφορούν δεν είναι δύσκολο να κάνεις ένα raid5 array που να ξεπερνά τα 16TB.

 

Πρέπει να κρατάει pointers από το ένα κομμάτι στο άλλο και όταν η εφαρμογή ζητήσει data από τη μνήμη ο kernel θα πρέπει να πηγαίνει από address space σε address space μέχρι να τη βρεί. Και όπως ακριβώς και στους δίσκους, το fragmentation προκαλεί εκτός από χαμηλό response time και πολύ αυξημένες πιθανότητες για data corruption.

Όσο για το θέμα του PAE που κράζει ο Torvalds, έχει ένα δίκιο αλλά οχι απόλυτο. Το PAE είναι μιά hack-ιά ακόμα για να μπορέσουν 32-bit λειτουργικά να δούνε και να διαχειριστούν RAM μεγαλύτερη των 4Gb. Ο τρόπος που το κάνουν αυτό είναι αρκετά απλός, με μιά ειδική διαδικασία, αλλάζει το mapping της RAM από 32bit σε 32+4 = 36, 2^36=64Gb. Δέν θα αναλύσω τον τρόπο που γίνεται αυτό αλλά το αποτέλεσμα αυτής της μαϊμουδιάς είναι οτι το λειτουργικό παρότι πλέον βλέπει και μπορεί να διαχειριστεί περισσότερη μνήμη, ο περιορισμός που υπάρχει στα 32-bit λειτουργικά που λέει οτι ο kernel μπορεί να πάρει μέχρι 1Gb μνήμης και οι υπόλοιπες εφαρμογές μέχρι 3, δέν αλλάζει. Δηλαδή ακόμα και αν έχει κάποιος 64Gb σε 32-bit + PAE λειτουργικό, ουσιαστικά ο kernel δέν μπορεί να διαχειριστεί πάνω από 3Gb από αυτά τα data και εκεί γίνονται διάφοροι χειρισμοί για να μήν χάνονται τα data που δέν είναι "διαχειρίσιμα" πέραν των 3Gb δηλαδή. Βέβαια αυτό σημαίνει οτι ο kernel έχει να κάνει και extra δουλειά γιατί εκτός από τα προηγούμενα που λέγαμε για fragmentation και μετάβαση από ένα σημείο του adress space στο άλλο για την ίδια εφαρμογή, πρέπει να μπορεί να πάει και στην extra μνήμη, εκτός του ορίου των 3Gb (για εφαρμογές) άρα έχει περισσότερους memory pointers να διαχειριστεί.

 

+1

 

Όπως ανέφερε ο NullScan, ο χώρος παραμένει 32bit δηλαδή ακόμη και 64GB μνήμη να έχουμε, μια εφαρμογή (τυπικά) μπορεί να προσπελάσει μόνο μέχρι 4GB. Δηλαδή δεν μπορούμε να δώσουμε σε μια απαιτητική mysql 6GB απλά μπορούμε να δώσουμε 3GB σε μια Χ εφαρμογή και 3GB σε μια άλλη Ψ. Αυτή είναι η τυπική συμπεριφορά. Το λειτουργικό όμως μπορεί να υλοποιεί διάφορα κόλπα σε βάρος της απόδοσης ώστε να δώσει παραπάνω από 4GB σε μία εφαρμογή.

 

Επίσης κάτι που είναι σημαντικό και συνήθως δεν χτυπάει στο μάτι είναι αυτό που είπε ο NullScan ότι ο πυρήνας κρατάει pointers. Ο πυρήνας έχει μεν στη διάθεση του 1GB αλλά πρακτικά έχει λιγότερο. Από το 1GB ένα μικρό ποσό (νομίζω 128MB γιατί όταν bootάρει ένας 32bit πυρήνας συνήθως αναφέρει 896MB available) δεσμεύεται για διάφορα πράγματα όπως να φορτώνονται modules, να γίνονται map registers, μνήμες των pci συσκευών και γενικά για ό,τι πράγματα χρειάζεται ο πυρήνας.

 

Όπως καταλαβαίνουμε, αυτοί οι πίνακες με τους pointers για το ποιο κομμάτι μνήμης βλέπει ποια εφαρμογή χρειάζονται μνήμη και όσο αυξάνει το fragmentation τόσο πιο πολλοί πίνακες χρειάζονται. Έτσι υπάρχει περίπτωση ενώ έχουμε πολύ ελεύθερη μνήμη, αυτή να μην μπορεί να χρησιμοποιηθεί επειδή έχει τελειώσει η lowmem και δεν μπορούν να κρατηθούν άλλοι pointers. Μια πολύ γνωστή περίπτωση είναι ενός τύπου που είχε 12GB μνήμη και έτρεχε 32bit πυρήνα όπως βλέπουμε εδώ.

 

> But this problem is already an issue, Anton recently had a case where a

> 12GB highmem box locked up due to NTFS running out of lowmem - or

> something like that.

 

Yeah. I always considered HIGHMEM to just be unusable. It's ok for

extending to 2-4GB (ie HIGHMEM4G, not 64G), and it's probably borderline

usable for 4-8G if you are careful.

 

But quite frankly, I refuse to even care about anything past that. If you

have 12G (or heaven forbid, even more) in your machine, and you can't be

bothered to just upgrade to a 64-bit CPU, then quite frankly, *I*

personally can't be bothered to care.

 

That's my personal opinion, and I realize that some of the commercial

vendors may care about their insane customers' satisfaction, but I'm

simply not interested in insane users. If they have that much RAM (and

bought it a few years ago when a 64-bit CPU wasn't an option), they can't

be poor.

 

So the _only_ explanation today for 12GB on a 32-bit machine is

(a) insanity

or

( being so lazy as to not bother to upgrade

and in either case, my personal reaction is "I'm *not* crazy, and yes, I'm

lazy too, and I can't give a rats *ss about those problems".

 

HIGHMEM was a mistake in the first place. It's one that we can live with,

but I refuse to support it more than it needs to be supported. And 12GB is

*way* past the end of what is worth supporting.

 

Linus

Άλλη μια περίπτωση που θυμάμαι ήταν ενός τύπου που αναβάθμισε τη μνήμη ενός server σε 24GB ή 32GB και το FreeBSD δεν bootαρε καν λόγω προβλημάτων με την PAE και τις PCI συσκευές.

 

Μια παρεμφερής ιστορία γίνεται και με το filesystem XFS. Το XFS από τη μάνα του αποθήκευε τις inodes μέσα στο 1ο TB ώστε να μπορούν να προσπελαστούν από 32bit εφαρμογές. Αυτό είχε ως αποτέλεσμα πχ να έχεις ελεύθερο χώρο 15TB αλλά να μην μπορείς να δημιουργήσεις νέα αρχεία επειδή ο χώρος κάτω από το 1TB είχε τελειώσει οπότε δεν μπορούσαν να δημιουργηθούν νέα inodes.

 

Τέλος να αναφέρουμε ότι δεν είναι απαραίτητο να χρησιμοποιεί ένα λειτουργικό αυτό το διαχωρισμό πυρήνα εφαρμογών (1GB/3GB σε linux, 2GB/2GB σε windows) αλλά μπορεί να βλέπει και ο πυρήνας και οι εφαρμογές όλη τη διαθέσιμη μνήμη. Έτσι όμως για κάθε μικρό ποσοστό μνήμης που θα χρειάζεται μια εφαρμογή ή ο πυρήνας θα πρέπει να γίνεται αυτή η δουλειά με τους pointers με βαριά χρήση των TLB το οποίο θα ρίξει πολύ την απόδοση για αυτό ο Torvalds αρνήθηκε να το εισάγει.

 

Με λίγα λόγια, καλό είναι να χρησιμοποιούμε 64bit πυρήνα εκτός και αν έχουμε πολύ καλό λόγο για το αντίθετο.

 

Σημειοτέον: Είναι πιθανό να περιέγραψα κάποια λειτουργία ανεπαρκώς ή λανθασμένα.

[hawkpilot]

Χωρίς να θέλω να προσβάλω ή υποτιμήσω κάποιον από όλα αυτά που ήδη γράφτηκαν, νομίζω ότι ψυρίζετε τη μαϊμού. Δεν καταλαβαίνω γιατί τόση ανάλυση περί πυρήνα x86/x64 όταν η επιλογή είναι τόσο... απλή και η εξής μία: με 4GB+ RAM ή και με λιγότερα, εφόσον πρόκειται να γίνει αναβάθμιση σύντομα, πάμε καρφί για x64. Ειλικρινά αδυνατώ να καταλάβω αυτούς που τρέχουν x86 λειτουργικό με 8 ή και 12GB RAM εκτός κι αν υπάρχουν πολύ "ειδικές" συνθήκες.

[mandos]

Φαντάζομαι ότι όλη η κουβεντά (και του Torvalds) είναι γιατί κάποιοι γράφουν στο νετ ότι έχω 12gb ram και θέλω 32bit κτλ κτλ για τους δικούς τους λόγους και όλοι οι υπόλοιποι μπαίνουν σε σκέψεις για το τι πρέπει να βάλουν.

 

Δεν είναι ότι το ψυρίζουμε, απλά ο κόσμος έχει χάσει την μπάλα. Βεβαία με το δίκιο σου θα μου πεις ότι αυτός ο κόσμος δεν διαβάζει τι λέει ο Torvalds, και θα έχεις δίκιο. Αλλά αν κάποιος πέσει επάνω στο άρθρο ας μάθει και δύο πράγματα.

Ήταν ωστόσο η πηγή για κάποια πολύ ωραία posts (και λίγη ιστορία).

 

άσχετο υγ: τελευταία πάντως πιο συχνά βλέπω pc με 2gb και 64bit παρά με 6gb και 32

[imitheos]

Χωρίς να θέλω να προσβάλω ή υποτιμήσω κάποιον από όλα αυτά που ήδη γράφτηκαν, νομίζω ότι ψυρίζετε τη μαϊμού. Δεν καταλαβαίνω γιατί τόση ανάλυση περί πυρήνα x86/x64 όταν η επιλογή είναι τόσο... απλή και η εξής μία: με 4GB+ RAM ή και με λιγότερα, εφόσον πρόκειται να γίνει αναβάθμιση σύντομα, πάμε καρφί για x64. Ειλικρινά αδυνατώ να καταλάβω αυτούς που τρέχουν x86 λειτουργικό με 8 ή και 12GB RAM εκτός κι αν υπάρχουν πολύ "ειδικές" συνθήκες.

 

Αυτός που έχει 4GB+ εννοείται πως βάζει 64bit. Το νήμα απευθύνεται (τουλάχιστον έτσι το κατάλαβα εγώ) σε αυτούς που έχουν 1GB-4GB και έχουν διαβάσει κάπου ότι το 64bit είναι βαρύ και ότι αν έχει <4GB δεν κερδίζει τίποτα να το βάλει.

 

Αυτό που λέει ο Torvalds και εξήγησε ο NullScan είναι ότι λόγω του τρόπου λειτουργίας της virtual memory, και 1GB να έχεις (άσχετα αν πρόκειται να κάνεις αναβάθμιση σύντομα ή όχι) θα κερδίσεις με το να τρέχεις 64bit.

[corrupted]

Ο σταθερος μου εχει 2GB DDR2. Απο προσωπικη εμπειρια με arch x86 και arch x64, δεν εχω δει καμια διαφορα στη ταχυτητα. Αλλα αφου το λετε οτι κερδιζεις με x64, το πιστευω..

[martinoff]

μα δεν νομίζω να τίθεται θέμα ποιο είναι ποιο γρήγορο, όπως είπε και ο nullscan δεν έχει λόγο να είναι ποιο γρήγορο (για αυτό δεν είμαι και πολύ σίγουρος. μπορεί να κάνω λάθος)

κάποτε ήμασταν με i386 μετά πήγαμε σε i686 ε τώρα είμαστε σε x86_64 τι το σκαλίζεις το 686

πάει, μας άφησε χρόνους, τελείωσε, THE END !