On Mon, May 14, 2007 at 02:42:11PM +0300, Shachar Shemesh wrote: > Muli Ben-Yehuda wrote: > > Hmm? that doesn't sound correct. All PAE does it make it possible to > > have 36-bits PFNs in the PTEs, so that your physical addressability is > > up to 64GB. You *can* address all 64GB of physical memory "at the same > > time". In other words PAE lets you map 4GB of virtual -> 64GB of > > physical. > > > Then maybe the misunderstanding is mine. > > As far as I understand things, you cannot have the following simple loop: > > for( i=0; i<size; ++i ) dst[i]=src[i]; > > copy data from one place to the other if "size" is over 4GB, even with > PAE. Would you say that statement is false? If it isn't, then you cannot > address more than 4GB of memory at the same time.
You are confusing *virtual* memory and *physical* memory. PAE has nothing to do with virtual memory and everything to do with physical memory. On a 32-bit platform, pointers are limited to addressing 4GB (== 2^32) of virtual memory. However, the 32-bit x86 platform also had a related limitation with regards to *physical memory*. Actually, two limitations: first, there were only 32 address lines to the memory bus, so only addresses in the range 0-4GB could be communicated to the memory bus. Second, the page table format (specifially, the page table entry (PTE) format) specified only 32 bits for the physical address. PAE solved both of these issues: 4 more address lines were added, and the PTE format was changed to 36-bits for the physical address. That's how you get 4GB of virtual adddressability and up to 64GB of *physical* addressability. > I don't know the mechanics of PAE. Did it resurrect the dreaded segment > registers? Is it a part of the MMU mapping? See above, or your favorite search engine :-) > > Again, this is misleading. It's only a problem with the way it's > > implemented in *linux* on *x86-32*, using mem_map and allocating page > > tables from low-mem (which we don't do any more if you have > > CONFIG_HIGHPTE enabled). Alternative implementations are definitely > > possible. > > > You still need to keep track of which virtual memory belonging to > which context goes in which physical address/swap page. The more > physical storage you have, the more you have to keep track of, the > more memory you need for that. This means that you may delay the > problem, but more memory always seems to mean more overhead. More accurate would be to say that more physical memory requires more work to keep track off, but you can trade-off computation and storage when performing that work. > My point was that the basic kernel-managed resource called "virtual > memory" becomes scarcer as more physical memory is added, which is > something of an absurd, which is why the 4/4 patch was originally > created. .. and my point was that this is a Linux design and implementation issue, rather than a universal truth (unless you restate it as I did above in terms of computation vs. storage overhead). Cheers, Muli ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
