virtual memory 4521

Andi Kleen

I fully agree. I should have been clearer in specifying that the "easy" implementation (where the OS can use PAE storage for "normal" system memory) needs a certain amount of storage in the OS's segment for each managed page of physical memory, and that sets an upper limit to PAE's usefulness. Of course that buttumes the OS doesn't take the *really* easy approach and just ignores the extra storage except to give access to them to applications via some API or doing something useful like paging there.

What you don't want to be doing is chasing pointers through the non-addressable "extended" storage.

You can look at the necessary page management structures a few different ways, but (with 4KB pages) you usually end up needing 1-4% of the physical storage for management structures*. For 64GB, that means you need 650-2600MB of memory just for managing the extended storage. Obviously the higher number isn't going to fit well in a typical 2GB OS segment. Even the (very optimistic) lower number is doable with a 2GB OS segment, but takes two thirds the OS's space with a 1GB segment (and the OS has other things to do, of course).

Once you get past that point, it's probably best just to have the OS mostly ignore the remaining storage, except, perhaps to provide some sort of minimal interface to it (using it as fast paging storage would be a good use).

*For example, each page of real memory implies the existence of some number of PTEs. Obviously it needs one for the actual active mapping, but there will be some level of overcommit, plus some unused space in the page tables (which are fixed in size), increasing the effective "size" of each PTE. Let's be generous and say you need 24 bytes of PTEs (eg 3 x 8 bytes). Then you need a few items buttociated with each real page. For example a pointer back to the address space and page slot the real page is mapped to, some status fields for things like page locks, change-reference history, probably a couple of linked list pointers. Optimistically say another 20 bytes. So there's 44 bytes right there, or 44-4096 or 1.1%.