OSDev.org

I know with paging, a process can get a 4GB virtual memory on a typical 32bit PC. I wonder how large can the virtual memory be with only segmentation, no paging. I know paging is better and more popular. I just want to know the answer.

For example, if I designed an OS which decides all the segments a process can have sum up to 64MB, does this mean the virtual memory is only 64MB? So can segmentation achieve a large virtual memory like paging, along with good protection, separating a process from the others?

Thanks in advance. Sorry if the question is stupid. Reading much information about segmentation and paging has my brain messed up.

If you don't use paging you have no virtual memory at all. Only linear addresses which are converted to physical addresses using segmentation (checking the limit and adding a base). One segment can be up to 4GB in size, if it starts at 0 and it's limit is 0xFFFFFFFF.
Of course you could separate processes using segmentation, but you need a consecutive block of physical memory which is the same size as the segment. With paging you can map a virtual 4k block to any physical block. Nowadays segmentation isn't used anymore.

Hi,

angwer wrote:I know with paging, a process can get a 4GB virtual memory on a typical 32bit PC. I wonder how large can the virtual memory be with only segmentation, no paging. I know paging is better and more popular. I just want to know the answer.

For example, if I designed an OS which decides all the segments a process can have sum up to 64MB, does this mean the virtual memory is only 64MB? So can segmentation achieve a large virtual memory like paging, along with good protection, separating a process from the others?

Thanks in advance. Sorry if the question is stupid. Reading much information about segmentation and paging has my brain messed up.

If you treat the segment as part of a virtual address (e.g. 16-bit segment + 32-bit offset = 48-bit virtual address), then a quick calculation will give you an extremely wrong answer. It will be wrong because segments would have to overlap in that scheme.


In theory; it would be possible to have both a GDT and an LDT for each process; so that each process can have up to about 16381 different segments. When the program loads a segment register it will either work (descriptor is currently present) or you'd get a GPF. The GPF handler would either save the old segment's data to disk and reuse that RAM, or (if the old segment's data is still being used via. a different segment register) find some free RAM; then load the segment's data from disk into that RAM, fix the base address in the descriptor and make it "present" again; then let the program load the segment register.

For the segments to be independent (and not overlapping) you'd need to limit the maximum size of a segment to "size of RAM / number of segments that can be in use at a time". There's 4 GiB of linear address space, but because of holes (for APICs, ROMs, PCI, etc) you're probably only going to be able to use a maximum of about 3 GiB of RAM. There are 6 segment registers (CS, SS, DS, ES, FS, GS) so the number of segments that can be in use at a time is 6.

This means that (for best case) each segment would be a maximum of 512 MiB; and therefore each process can have 16381*512 MiB of virtual space (almost 8 TiB).

Of course this may not be fast...


Cheers,

Brendan

Thanks you both. Get a better understanding of segmentation.