On 08-Nov-00 Jeroen Ruigrok van der Werven wrote:
> Reading some documents and sources I came to the following conclusion:
>
> We support 4 Kbyte pages and 4 Mbyte pages, but we do not support 2
> Mbyte pages. On IA-32 at least.
>
> Is there a reason to?
Heh, PSE and PAE are two different things. PSE allows you to specify that the
pointer to the final layer page table should map a large contiguous page
insetad of pointing to a page table that maps several 4k pages. A page table
on IA-32 is 4096 bytes long. Under normal paging without PAE, each entry in a
page table is 4 bytes long, so that each leaf page table can map 1024 4k pages,
or 4 Meg. If you turn PSE on, then a "large" page mapsa contiguous 4mb page.
PAE changes the paging a bit to allow for 36-bit physical addresses. It still
uses 32-bit virtual addresses, however. To accomodate the larger number of
bits for physical addresses, each page table entry becomes 8 bytes long instead
of 4 bytes. Thus, each leaf page table can only map 512 4k pages, or 2 Mb. As
a result, when PSE is turned on, a "large" page maps a contiuous 2mb page.
Since each level of page tables with PAE only uses 9 bits intead of 8 (512
entries instead of 1024), an additional layer of page tables is added at the
top with a small 16-entry table that points to the page directories. Without
PAE, you normall have one page directory that is pointed to be %cr3.
Here's a diagram that might help:
Page Size Table:
| Small Pages | Large Pages
---------------------------------------
Normal | 4k | 4k
PSE | 4k | 4m
PAE | 4k | 4k
PAE + PSE | 4k | 2m
The benefits of PAE are that you can support a machine that has more than 4gb
of phyiscal ram, up to 64gb. However, the virtual address space is still 4gb,
so a process (and kernel with the current way we do our virtual address
mapping) must still fit into a 4gb space.
> I could understand that some people would prefer 2 Mbyte pages in some
> situations. But looking at pmap.c I see we only test CPUID_PSE and
> don't use CPUID_PAE anywhere.
Actually, the 2mb pages really don't buy us anything. We only use large pages
now to map the kernel, AFAIK.
> Since pmap.c is in a MD location it wouldn't be hard to extend the code
> to do this.
>
> Would this needlessly complicate a lot of things in our code? i could
> envision that our VM and related code should be usable no matter what
> the page size is. This will certainly improve future ports to new
> architectures with different page sizes.
Adding in PAE support is not an easy task. Many places in the x86 pmap code
assume that a page table entry is an int. This is not true in the case of PAE.
There are also other problems that Peter Wemm could scare you with. :) There
is some desire to do this, but it won't be easy.
> Are there even more arguments in favor or against?
>
> I'd like to hear some thoughts. :)
I'm sure Peter can correct this and fill in any holes as well as offer guidance
to anyone who is masochistic enough^W^Wwilling to work on this.
> --
> Jeroen Ruigrok van der Werven Network- and systemadministrator
> <[EMAIL PROTECTED]> VIA Net.Works The Netherlands
> BSD: Technical excellence at its best http://www.via-net-works.nl
> Wisdom is the difference between knowledge and experience...
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
