4 ms·
It's easy to make that mistake at first, but it is a very important distinction. Most of the time, for most processes, most of that space is unallocated. Howeve
by a-priori 18y ago
It's easy to make that mistake at first, but it is a very important distinction. Most of the time, for most processes, most of that space is unallocated. However, since it's basically impossible to change the size of the kernel area without relinking the process binaries, and since that area is shared between all processes, the size of that area has to remain fixed.
It is interesting that Linux and NT differ. Perhaps this is due to the fact that NT needs more kernel memory to house, e.g. the windowing system, whereas Linux systems put X in userspace? I'm speculating here.
Something I never considered: that design difference probably makes Wine's job easier, because between the 2GB and 3GB marks is a region of memory the Windows process assumes is inaccessible, yet in Linux is in userspace. They could (and probably do) load the Wine libraries here without interfering with the Windows process. It also means that it would be very difficult to implement Wine's complement, a way of running Linux binaries on Windows.
- brl 18y agoIt's pretty arbitrary really. It's rare to need more than 2 gigs of memory in a single user process. On the other hand, the more address space you have in the kernel the easier it is to use spare memory for IO buffer caching.
- kragen 18y agoLinux used to be 2GiB/2GiB too, just like NT. It changed because people with big processes were unhappy; for a while there was an unofficial kernel patch for the 3GiB/1GiB split. Maybe NT didn't change because not as many people were running supercomputers on NT, or because changing NT is harder. You don't have to relink your userland binaries to do this because they don't contain virtual addresses of kernel data structures, only their own data structures. Expanding the space available for mmap won't force those data structures to move. You can pretty much load Wine libraries wherever you want; it's pretty rare for a program to break if memory it assumed was unmapped gets used for a library, and programs that break that way will have a lot of trouble when Windows versions change too. Generally programs are only linked with knowledge of where they themselves will be loaded in virtual memory. (Linux ELF shared libraries don't even know that.) All the other addresses are given to the program at startup. It is unusual for Linux binaries to believe that they will be loaded above 2GiB; the usual start address is 0x08048000. Here's the memory map of a process running under Wine: http://gist.github.com/53853 http://gist.github.com/53853 --- note that there's a lot of Wine and X11 stuff loaded below 2GiB (0x80000000).