| the "traditional" option in both windows and linux on 32-bit is 2GB "user", 2GB kernel, meaning that a given user process can only have 2GB mapped at a time. If you have sufficient RAM and/or backing store, you can have lots of processes each with a different 2GB, but each process only gets 2GB of virtual memory space to play with.
In Windows with /3GB or Linux with CONFIG_3GB, the split is 3GB for userspace, 1GB for kernel. This does pretty much what you'd expect. The kernel has a tighter memory constraint to work under, but each application process can now map 3GB instead of 2GB. Useful for databases, sometimes.
On Linux specifically there's also an option to use a "4GB/4GB split", which allows each process to use essentially the whole possible VM and give the kernel its own 4GB. Obviously there's some trickery involved in this; processes and the kernel each have their own completely separate set of mappings, and the mappings have to be reset every time we enter or exit the kernel. Plus copy-to/from-user operations get more messy. Obviously the upshot of all that is significant overhead... but there are some people with crazy applications where the advantages of being able to keep a 33% larger working set outweigh the disadvantage of making everything else slower. |
