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. I don't know the mechanics of PAE. Did it resurrect the dreaded segment registers? Is it a part of the MMU mapping? > This is misleading. We can have the kernel "available for us" just > fine even if is not mapped in the user's address space. The reason it > is mapped (on x86-32 only!) in every process's address space is to cut > down on context switch costs, since we aren't really switching address > spaces (which would necessitate a TLB flush). > I actually talked about both the 32 bit issue, as well as the context switch issue, later on. As there is no PAE on 64 bit anyways, I fail to see the point here. As a side note, I'll point out that as far as I understand it, 64 bit does NOT avoid this problem. It just uses the end of the 64bit address range, instead of the 32 bit address range. This means that 32 bit programs running on 64 bit platforms never see the missing part (as their virtual address space is truncated early anyways), and 64 bit programs will not have any problems today because nobody has yet figured out a way to exhaust 16 exabyte of memory. This does NOT mean, however, that there is no theoretical problem. > 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. Again, I may be missing something here. >> the more physical memory >> you, the less memory each user space program can use! >> > > "The less *virtual* memory each user space program can use in a single > addres space" is what you meant to say. That's total nitpicking, but ok. Just replace "program" with "process" and I stand by my original statement. > It's trivial to fork() and > thus get a second address space to play with. Additionally, you could > use something like shared page tables to solve (or at least mitigate) > the same problem. > Yes, you could do all those. You can also map a large file on disk to memory in segments, picking whatever you currently need to use. There are lots of way to mitigate the problem And they require special handling by the program. 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. > MAP_FIXED will make this simpler. > While true, MAP_FIXED will also fail if the specific address you asked for happened to be allocated, even if memory in the tested region is available. To me, this means it is less effective as a detection tool, as it generates false negatives. > I applaud your taking the time to write such a detailed > explanation. > Despite the inaccuracies? :-) Thanks. > Cheers, > Muli > Shachar ================================================================= 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]
