Dean Kent (dkent@realworldtech.com) on 5/14/07 wrote:
---------------------------
>anon2 (example@example.net) on 5/14/07 wrote:
>---------------------------
>>No it is NOT. I have no idea where you got this impression. The requirements are (as Linus already explained):
>>
>>Virtual address space >= user address space + kernel address space
>>Kernel address space >= physical memory size + memory-mapped I/O size + kernel virtual mappings
>
>It seems odd to me that virtually *every* address must be mapped, whether actually used or not.

I don't understand what you are saying is odd here. The kernel uses all of physical memory, at all times. For cacheing if it can't find a better use. Doing less would be pointlessly throwing performance away.

There are kinds of cacheing where the kernel rarely or never needs to directly access the memory, which allows it to use memory not permanently mapped into the kernel's address space, but there's extra overhead if it does have to access it directly, and such memory can't be used for all purposes. This is Linux's HIGHMEM kludge.

>>Assuming you want to allow a user virtual address space
>>on the order of physical memory size, virtual memory size should be at least 2x physical memory.
>
>Even if *none* of your apps uses that much memory?

You need room in the total virtual address space for the kernel's needs (all of physical memory, if the kernel is doing its job right), plus the maximum potential user address space. Some processors have additional virtual address bits in the form of "address space IDs" which allow the 2^32 limit to be stretched, but the x86-32 whose PAE we are talking about does not.

Of each user address space, some fraction is mapped. Some fraction of the mapped space is backed by physical (resident) memory pages. Physical memory needs to be large enough to hold the latter. Virtual memory needs to be large enough to hold the former, which is always larger.

>Shouldn't an address space
>only be as large as it needs to be?

The basic size of an address space is fixed by the processor architecture. On x86-32, it is 2^32 bytes. (This may be further limited by the processor silicon, but no existing x86-32 imposes such a limit.)

Software may decide what fraction of that address space can be accessed, but its basic size is carved in silicon; it cannot be changed dynamically.

> Shouldn't virtual address pages be allocated only when actually needed?

They mostly are. One exception is the user/kernel split, which has to be in the same place in every process, so moving it dynamically is thoroughly impractical.

Instead, the virtual address space is statically divided into a "user region" which is different for every process and a "kernel region" which is shared.

>>The resident set size has NOTHING do do with it. The user (virtual) address space
>>contains all mapped addresses, both resident and non-resident. You need space for all of that.
>
>You need space for what you use, it seems to me. If you are allocating pages for
>unused memory, that seems to be a waste of effort to me.

I don't understand what "space" you are talking about. There are two kinds of space: virtual and physical. You need virtual address space for all virtual (potentially usable) addresses. You need physical memory for the subset of virtual addresses that you actually use.

When you memory-map a resource, you consume virtual address space equal to the size of that resource, but (modulo kernel bookkeeping) no physical memory. When you access that resource, you additionally need physical memory to hold the portion of the resource that you access.