Why our server with centOS i686 showing 14 GB usable RAM
We have CentOS server 6 i686 (installed by previous employee) on blade server which is having 32GB RAM (4GB x 8 slots).
The usable RAM is 14GB.
My question is why it is showing 14GB instead of 4GB, which is maximum for 32-bit OS.
Can I remove RAM in 4 slots to have total 16GB RAM, then what will be the usable RAM?
memory operating-systems 32-bit paging
add a comment |
We have CentOS server 6 i686 (installed by previous employee) on blade server which is having 32GB RAM (4GB x 8 slots).
The usable RAM is 14GB.
My question is why it is showing 14GB instead of 4GB, which is maximum for 32-bit OS.
Can I remove RAM in 4 slots to have total 16GB RAM, then what will be the usable RAM?
memory operating-systems 32-bit paging
Most (all?) 32-bit Linuxes can access more than 4GB of ram, with PAE. Are you 100% positive that every ram stick is 4GB? Or that the computer can use all 8 slots together?
– Xen2050
Feb 6 at 6:46
@EdGrimm It is true that 32-bit x86 processors are not limited to 4 GB, but "bank switching" is not how it's done. The mechanism is called PAE. It is simply a slight modification of the already-existing page table mechanism. 32-bit Windows Server systems can take advantage of this. 32-bit Windows non-Server SKUs ("client" versions) cannot, but this is only because the OS deliberately limits itself to 4 GB RAM - they can still run with PAE enabled. See en.wikipedia.org/wiki/Physical_Address_Extension
– Jamie Hanrahan
Feb 6 at 15:08
@EdGrimm Also: the MMU is part of the CPU chip, not on the motherboard.
– Jamie Hanrahan
Feb 6 at 15:10
After reading your link... other than terminology changes, reducing the size of the banks down to 4K, and moving it onto the CPU, that still reads like bank switching to me. Admittedly, this is an industry that gets very particular about terminology, and doesn't like to admit general terms still apply even though the chip makers have pushed a new term to honor having moved the process onto the CPU.
– Ed Grimm
Feb 7 at 0:01
add a comment |
We have CentOS server 6 i686 (installed by previous employee) on blade server which is having 32GB RAM (4GB x 8 slots).
The usable RAM is 14GB.
My question is why it is showing 14GB instead of 4GB, which is maximum for 32-bit OS.
Can I remove RAM in 4 slots to have total 16GB RAM, then what will be the usable RAM?
memory operating-systems 32-bit paging
We have CentOS server 6 i686 (installed by previous employee) on blade server which is having 32GB RAM (4GB x 8 slots).
The usable RAM is 14GB.
My question is why it is showing 14GB instead of 4GB, which is maximum for 32-bit OS.
Can I remove RAM in 4 slots to have total 16GB RAM, then what will be the usable RAM?
memory operating-systems 32-bit paging
memory operating-systems 32-bit paging
asked Feb 6 at 6:17
TejasTejas
2081314
2081314
Most (all?) 32-bit Linuxes can access more than 4GB of ram, with PAE. Are you 100% positive that every ram stick is 4GB? Or that the computer can use all 8 slots together?
– Xen2050
Feb 6 at 6:46
@EdGrimm It is true that 32-bit x86 processors are not limited to 4 GB, but "bank switching" is not how it's done. The mechanism is called PAE. It is simply a slight modification of the already-existing page table mechanism. 32-bit Windows Server systems can take advantage of this. 32-bit Windows non-Server SKUs ("client" versions) cannot, but this is only because the OS deliberately limits itself to 4 GB RAM - they can still run with PAE enabled. See en.wikipedia.org/wiki/Physical_Address_Extension
– Jamie Hanrahan
Feb 6 at 15:08
@EdGrimm Also: the MMU is part of the CPU chip, not on the motherboard.
– Jamie Hanrahan
Feb 6 at 15:10
After reading your link... other than terminology changes, reducing the size of the banks down to 4K, and moving it onto the CPU, that still reads like bank switching to me. Admittedly, this is an industry that gets very particular about terminology, and doesn't like to admit general terms still apply even though the chip makers have pushed a new term to honor having moved the process onto the CPU.
– Ed Grimm
Feb 7 at 0:01
add a comment |
Most (all?) 32-bit Linuxes can access more than 4GB of ram, with PAE. Are you 100% positive that every ram stick is 4GB? Or that the computer can use all 8 slots together?
– Xen2050
Feb 6 at 6:46
@EdGrimm It is true that 32-bit x86 processors are not limited to 4 GB, but "bank switching" is not how it's done. The mechanism is called PAE. It is simply a slight modification of the already-existing page table mechanism. 32-bit Windows Server systems can take advantage of this. 32-bit Windows non-Server SKUs ("client" versions) cannot, but this is only because the OS deliberately limits itself to 4 GB RAM - they can still run with PAE enabled. See en.wikipedia.org/wiki/Physical_Address_Extension
– Jamie Hanrahan
Feb 6 at 15:08
@EdGrimm Also: the MMU is part of the CPU chip, not on the motherboard.
– Jamie Hanrahan
Feb 6 at 15:10
After reading your link... other than terminology changes, reducing the size of the banks down to 4K, and moving it onto the CPU, that still reads like bank switching to me. Admittedly, this is an industry that gets very particular about terminology, and doesn't like to admit general terms still apply even though the chip makers have pushed a new term to honor having moved the process onto the CPU.
– Ed Grimm
Feb 7 at 0:01
Most (all?) 32-bit Linuxes can access more than 4GB of ram, with PAE. Are you 100% positive that every ram stick is 4GB? Or that the computer can use all 8 slots together?
– Xen2050
Feb 6 at 6:46
Most (all?) 32-bit Linuxes can access more than 4GB of ram, with PAE. Are you 100% positive that every ram stick is 4GB? Or that the computer can use all 8 slots together?
– Xen2050
Feb 6 at 6:46
@EdGrimm It is true that 32-bit x86 processors are not limited to 4 GB, but "bank switching" is not how it's done. The mechanism is called PAE. It is simply a slight modification of the already-existing page table mechanism. 32-bit Windows Server systems can take advantage of this. 32-bit Windows non-Server SKUs ("client" versions) cannot, but this is only because the OS deliberately limits itself to 4 GB RAM - they can still run with PAE enabled. See en.wikipedia.org/wiki/Physical_Address_Extension
– Jamie Hanrahan
Feb 6 at 15:08
@EdGrimm It is true that 32-bit x86 processors are not limited to 4 GB, but "bank switching" is not how it's done. The mechanism is called PAE. It is simply a slight modification of the already-existing page table mechanism. 32-bit Windows Server systems can take advantage of this. 32-bit Windows non-Server SKUs ("client" versions) cannot, but this is only because the OS deliberately limits itself to 4 GB RAM - they can still run with PAE enabled. See en.wikipedia.org/wiki/Physical_Address_Extension
– Jamie Hanrahan
Feb 6 at 15:08
@EdGrimm Also: the MMU is part of the CPU chip, not on the motherboard.
– Jamie Hanrahan
Feb 6 at 15:10
@EdGrimm Also: the MMU is part of the CPU chip, not on the motherboard.
– Jamie Hanrahan
Feb 6 at 15:10
After reading your link... other than terminology changes, reducing the size of the banks down to 4K, and moving it onto the CPU, that still reads like bank switching to me. Admittedly, this is an industry that gets very particular about terminology, and doesn't like to admit general terms still apply even though the chip makers have pushed a new term to honor having moved the process onto the CPU.
– Ed Grimm
Feb 7 at 0:01
After reading your link... other than terminology changes, reducing the size of the banks down to 4K, and moving it onto the CPU, that still reads like bank switching to me. Admittedly, this is an industry that gets very particular about terminology, and doesn't like to admit general terms still apply even though the chip makers have pushed a new term to honor having moved the process onto the CPU.
– Ed Grimm
Feb 7 at 0:01
add a comment |
1 Answer
1
active
oldest
votes
instead of 4GB, which is maximum for 32-bit OS.
Programs on Linux (and most operating systems) don't deal with physical memory directly – they work with virtual addresses which are translated by the hardware according to a mapping that the OS configures.
So although 32-bit systems use 32-bit pointers and a program cannot see more than 4 GB of virtual memory at once, the page tables (virtual-to-physical memory mappings) can actually represent longer physical addresses than that. The corresponding x86 feature is called Physical Address Extension (also) and allows these mappings to resolve to 36-bit physical addresses.
This means that you could simultaneously have multiple processes mapped to different virtual 4 GB areas in the physical up-to-64 GB space. (The same happens if you run 32-bit processes on a 64-bit OS.)
Similarly, 16-bit systems could use more than 64 kB of physical memory through tricks such as segmentation (which on 8086 allowed effectively 20-bit physical addresses) or bank switching (which allowed remapping the same memory addresses to different physical areas, e.g. C64 or MS-DOS XMS/EMS).
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1402533%2fwhy-our-server-with-centos-i686-showing-14-gb-usable-ram%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
instead of 4GB, which is maximum for 32-bit OS.
Programs on Linux (and most operating systems) don't deal with physical memory directly – they work with virtual addresses which are translated by the hardware according to a mapping that the OS configures.
So although 32-bit systems use 32-bit pointers and a program cannot see more than 4 GB of virtual memory at once, the page tables (virtual-to-physical memory mappings) can actually represent longer physical addresses than that. The corresponding x86 feature is called Physical Address Extension (also) and allows these mappings to resolve to 36-bit physical addresses.
This means that you could simultaneously have multiple processes mapped to different virtual 4 GB areas in the physical up-to-64 GB space. (The same happens if you run 32-bit processes on a 64-bit OS.)
Similarly, 16-bit systems could use more than 64 kB of physical memory through tricks such as segmentation (which on 8086 allowed effectively 20-bit physical addresses) or bank switching (which allowed remapping the same memory addresses to different physical areas, e.g. C64 or MS-DOS XMS/EMS).
add a comment |
instead of 4GB, which is maximum for 32-bit OS.
Programs on Linux (and most operating systems) don't deal with physical memory directly – they work with virtual addresses which are translated by the hardware according to a mapping that the OS configures.
So although 32-bit systems use 32-bit pointers and a program cannot see more than 4 GB of virtual memory at once, the page tables (virtual-to-physical memory mappings) can actually represent longer physical addresses than that. The corresponding x86 feature is called Physical Address Extension (also) and allows these mappings to resolve to 36-bit physical addresses.
This means that you could simultaneously have multiple processes mapped to different virtual 4 GB areas in the physical up-to-64 GB space. (The same happens if you run 32-bit processes on a 64-bit OS.)
Similarly, 16-bit systems could use more than 64 kB of physical memory through tricks such as segmentation (which on 8086 allowed effectively 20-bit physical addresses) or bank switching (which allowed remapping the same memory addresses to different physical areas, e.g. C64 or MS-DOS XMS/EMS).
add a comment |
instead of 4GB, which is maximum for 32-bit OS.
Programs on Linux (and most operating systems) don't deal with physical memory directly – they work with virtual addresses which are translated by the hardware according to a mapping that the OS configures.
So although 32-bit systems use 32-bit pointers and a program cannot see more than 4 GB of virtual memory at once, the page tables (virtual-to-physical memory mappings) can actually represent longer physical addresses than that. The corresponding x86 feature is called Physical Address Extension (also) and allows these mappings to resolve to 36-bit physical addresses.
This means that you could simultaneously have multiple processes mapped to different virtual 4 GB areas in the physical up-to-64 GB space. (The same happens if you run 32-bit processes on a 64-bit OS.)
Similarly, 16-bit systems could use more than 64 kB of physical memory through tricks such as segmentation (which on 8086 allowed effectively 20-bit physical addresses) or bank switching (which allowed remapping the same memory addresses to different physical areas, e.g. C64 or MS-DOS XMS/EMS).
instead of 4GB, which is maximum for 32-bit OS.
Programs on Linux (and most operating systems) don't deal with physical memory directly – they work with virtual addresses which are translated by the hardware according to a mapping that the OS configures.
So although 32-bit systems use 32-bit pointers and a program cannot see more than 4 GB of virtual memory at once, the page tables (virtual-to-physical memory mappings) can actually represent longer physical addresses than that. The corresponding x86 feature is called Physical Address Extension (also) and allows these mappings to resolve to 36-bit physical addresses.
This means that you could simultaneously have multiple processes mapped to different virtual 4 GB areas in the physical up-to-64 GB space. (The same happens if you run 32-bit processes on a 64-bit OS.)
Similarly, 16-bit systems could use more than 64 kB of physical memory through tricks such as segmentation (which on 8086 allowed effectively 20-bit physical addresses) or bank switching (which allowed remapping the same memory addresses to different physical areas, e.g. C64 or MS-DOS XMS/EMS).
answered Feb 6 at 6:49
grawitygrawity
241k37508562
241k37508562
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1402533%2fwhy-our-server-with-centos-i686-showing-14-gb-usable-ram%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Most (all?) 32-bit Linuxes can access more than 4GB of ram, with PAE. Are you 100% positive that every ram stick is 4GB? Or that the computer can use all 8 slots together?
– Xen2050
Feb 6 at 6:46
@EdGrimm It is true that 32-bit x86 processors are not limited to 4 GB, but "bank switching" is not how it's done. The mechanism is called PAE. It is simply a slight modification of the already-existing page table mechanism. 32-bit Windows Server systems can take advantage of this. 32-bit Windows non-Server SKUs ("client" versions) cannot, but this is only because the OS deliberately limits itself to 4 GB RAM - they can still run with PAE enabled. See en.wikipedia.org/wiki/Physical_Address_Extension
– Jamie Hanrahan
Feb 6 at 15:08
@EdGrimm Also: the MMU is part of the CPU chip, not on the motherboard.
– Jamie Hanrahan
Feb 6 at 15:10
After reading your link... other than terminology changes, reducing the size of the banks down to 4K, and moving it onto the CPU, that still reads like bank switching to me. Admittedly, this is an industry that gets very particular about terminology, and doesn't like to admit general terms still apply even though the chip makers have pushed a new term to honor having moved the process onto the CPU.
– Ed Grimm
Feb 7 at 0:01