Re: large memory support for x86

From: Alexander Viro (
Date: Fri Oct 13 2000 - 14:34:32 EST

On Fri, 13 Oct 2000, Timur Tabi wrote:

> I understand that a normal virtual address (i.e. a pointer) can only address a
> single 32-bit (4GB) memory block. My point was that by also using more than
> one 16-bit selector, you can have multiple 4GB areas. So for instance,
> 1000:00000000 can point to one physical address, and 1001:00000000 can point a
> different physical address.

_All_ of them are piped through the 4Gb address space. I.e. every segment
is mapped to a part of the same (for all segments) 4Gb. That address space
is, in turn, mapped to 64Gb of physical memory. At any moment you can't
get more than 2^32 different elements of physical memory accessible, even
though you have 48 bits of address in the beginning and 36 bits in the

Think of it that way: we have two functions:

u32 map_segment(u48);
u36 map_paging(u32);

and processor does map_paging(map_segment(address)) when it calculates the
physical addresses. Even though both the range and domain are larger than
2^32, the number of different values is less or equal to it.

> Yes, this means that you need to use multiple selectors in order to access more
> than 4GB of virtual space.
> According to section 3.8 of Intel's P3 manual, Volume 3, enabling the PAE
> increases the size of the page table entries to 64 bits. There are other
> changes, such as extended the 20-bit page directory base address to 27 bits.
> All this means that a virtual address (selector:offset) can point to a physical
> address larger than 32 bits.

Virtual address gives linear address. _Then_ it is translated into
physical address. Page tables describe the latter mapping. Descriptor
tables - the former. Size of linear address is the bottleneck here and no
changes past that bottleneck can expand the number of possible values.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:25 EST