Hi Friends....
I want to know some offbit issues regarding RAM. this is no releavence with OSDev.. My proj is right now hibernated..... Anyways...
I want to know that what is the maximum amount of RAM does Fedora c5, CENTOS, Red HAT support? I know that it depends on processor. If we have 32 bit cpu then it can support 2^32 byte ram. But I have heard that thr are Linux versions available whc support 8 GB or 16 GB RAM on 32 bit machine.... ???
Can you help me out!!??
Maximum RAM support !!!?
Re:Maximum RAM support !!!?
Hi,
32 bit paging or no paging = up to 4 GB of RAM
PAE or PSE-36 paging (on 32-bit CPU) = up to 64 GB of RAM
PAE or long mode (on 64-bit CPU) = depends on CPU
Currently for 64-bit CPUs, physical addresses are either 36 bits wide or 48 bits wide. The current architectural limit for a 64 bit CPU is 56 bit wide physical addresses (which also applies to a 32-bit OS running on a 64-bit CPU using PAE, if PAE is used carefully). This means a 32 bit OS can use up to 65536 TB of RAM in very specific circumstances...
I should point out that at each place I wrote "RAM" above I should've written "accessable physical address space". This is because of ROMs, memory holes, etc. For example, with plain 32 bit paging you can access up to 4096 MB of physical address space, but even if the computer has 8192 MB of RAM you might only be able to access 3583 MB of it.
I'd also assume that different OSs place their own limits on how much RAM they can support, where this limit has nothing to do with the hardware. For example, a 32-bit OS using PAE might only be able to address 512 MB of RAM (or any other limit) due to the design of the memory manager used.
Cheers,
Brendan
I'm not sure about specific OS's, but for the architecture itself it goes like this:Viral wrote:I want to know that what is the maximum amount of RAM does Fedora c5, CENTOS, Red HAT support? I know that it depends on processor. If we have 32 bit cpu then it can support 2^32 byte ram. But I have heard that thr are Linux versions available whc support 8 GB or 16 GB RAM on 32 bit machine.... ???
32 bit paging or no paging = up to 4 GB of RAM
PAE or PSE-36 paging (on 32-bit CPU) = up to 64 GB of RAM
PAE or long mode (on 64-bit CPU) = depends on CPU
Currently for 64-bit CPUs, physical addresses are either 36 bits wide or 48 bits wide. The current architectural limit for a 64 bit CPU is 56 bit wide physical addresses (which also applies to a 32-bit OS running on a 64-bit CPU using PAE, if PAE is used carefully). This means a 32 bit OS can use up to 65536 TB of RAM in very specific circumstances...
I should point out that at each place I wrote "RAM" above I should've written "accessable physical address space". This is because of ROMs, memory holes, etc. For example, with plain 32 bit paging you can access up to 4096 MB of physical address space, but even if the computer has 8192 MB of RAM you might only be able to access 3583 MB of it.
I'd also assume that different OSs place their own limits on how much RAM they can support, where this limit has nothing to do with the hardware. For example, a 32-bit OS using PAE might only be able to address 512 MB of RAM (or any other limit) due to the design of the memory manager used.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
-
killedbydeath
Re:Maximum RAM support !!!?
you can access more than 4 gbytes of memory even without paging. 4 gbytes is not the memory limit, but the segment size limit. Which means that if you have multiple segments one on top of the other (not overlapping) , you 'll be able to access
Max GDT entries-1(don't forget the null descriptor) * 4 gb
Max GDT entries-1(don't forget the null descriptor
) * 4 gbRe:Maximum RAM support !!!?
Hi,
For 32-bit CPUs (with or without paging), it's impossible to create a segment where the base is > 4 GB, and all addresses wrap around at 4 GB.
For example, if you create a segment with base = 0xFFFFFFF0 and limit = 4 GB and then try to access offset 0x11 in this segment it will wrap around and you'll end up with physical address 0x00000001 (not physical address 0x100000001).
The only possible way this could work is by using swap space to extend physical memory. For example, have 50 segments that are 1 GB each and mark 46 of them as "not present". When a "not present" segment is accessed, you'd send a "present' segment to disk and load the new "not present" segment into RAM. This doesn't really count because you're not accessing more than 4 GB of physical address space (even though you would be accessing more than 4 GB of virtual address space without paging).
The only other way is to use FS and GS segment registers in long mode (where the base address can be > 4 GB and there is no address wrapping). This doesn't really count though because you can't enable long mode without using paging.
Cheers,
Brendan
Wrong.killedbydeath wrote:you can access more than 4 gbytes of memory even without paging. 4 gbytes is not the memory limit, but the segment size limit. Which means that if you have multiple segments one on top of the other (not overlapping) , you 'll be able to access
Max GDT entries-1(don't forget the null descriptor
For 32-bit CPUs (with or without paging), it's impossible to create a segment where the base is > 4 GB, and all addresses wrap around at 4 GB.
For example, if you create a segment with base = 0xFFFFFFF0 and limit = 4 GB and then try to access offset 0x11 in this segment it will wrap around and you'll end up with physical address 0x00000001 (not physical address 0x100000001).
The only possible way this could work is by using swap space to extend physical memory. For example, have 50 segments that are 1 GB each and mark 46 of them as "not present". When a "not present" segment is accessed, you'd send a "present' segment to disk and load the new "not present" segment into RAM. This doesn't really count because you're not accessing more than 4 GB of physical address space (even though you would be accessing more than 4 GB of virtual address space without paging).
The only other way is to use FS and GS segment registers in long mode (where the base address can be > 4 GB and there is no address wrapping). This doesn't really count though because you can't enable long mode without using paging.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re:Maximum RAM support !!!?
You can have whatever address you want as virtual. It's just limited to 32-bits because you can't use any more bits. That is then translated using segmentation to the intermediate form, linear addresses. This linear address is also 32-bit. You then map this linear address to a physical address using paging, ending up with a possibly larger address. Information theory says then, that you can't map onto all memory at the same time with one mapping (pigeonhole principle). You can make multiple mappings to use the rest in that case.
For AMD64, the first type is obliterated, the second is expanded to 48 bits and the third to 52-bits, possibly limited lower by implementation choices.
For AMD64, the first type is obliterated, the second is expanded to 48 bits and the third to 52-bits, possibly limited lower by implementation choices.
Re:Maximum RAM support !!!?
Hi,
For an example, this page in the Wikipedia claims that an 80386 has 64 Terabytes of virtual memory. I would assume this includes both GDT and LDT entries, or (8192 + 8192) * 4 GB = 64 TB.
While it would be technically possible to implement a system that supports almost (but not quite) 64 TB of virtual address space by swapping entire 4 GB segments to disk, it would also be extremely impractical.
Of course the Wiki page talks about the CPU alone, not a CPU and chipset combination. This opens up the possibility of special purpose chipsets - for example, something that implements bank switched RAM using an I/O port, where the bank switching is handled by exception handlers. In this case you could have almost 64 TB of virtual address space and almost 64 TB of physical RAM connected to a 32 bit CPU (but it still won't work in practice, as you'd need to have code, data and stack in the same segment).
Cheers,
Brendan
Just a note - I have seen web sites stating that the "virtual address space size" of an 80386 is huge, based on calculations similar to "number of segments * 4 GB".Candy wrote:You can have whatever address you want as virtual. It's just limited to 32-bits because you can't use any more bits. That is then translated using segmentation to the intermediate form, linear addresses. This linear address is also 32-bit. You then map this linear address to a physical address using paging, ending up with a possibly larger address. Information theory says then, that you can't map onto all memory at the same time with one mapping (pigeonhole principle). You can make multiple mappings to use the rest in that case.
For an example, this page in the Wikipedia claims that an 80386 has 64 Terabytes of virtual memory. I would assume this includes both GDT and LDT entries, or (8192 + 8192) * 4 GB = 64 TB.
While it would be technically possible to implement a system that supports almost (but not quite) 64 TB of virtual address space by swapping entire 4 GB segments to disk, it would also be extremely impractical.
Of course the Wiki page talks about the CPU alone, not a CPU and chipset combination. This opens up the possibility of special purpose chipsets - for example, something that implements bank switched RAM using an I/O port, where the bank switching is handled by exception handlers. In this case you could have almost 64 TB of virtual address space and almost 64 TB of physical RAM connected to a 32 bit CPU (but it still won't work in practice, as you'd need to have code, data and stack in the same segment).
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.