0xC0000000 on Linux. Mac OS X i386 sets the boundary at 0x00000000 :) This is yet another aspect where Mac OS X made a better choice than Linux, as this gives processes 4GB of virtual memory instead of only 3GB.
Seriously: there are trade offs everywhere. Initially, a 2/2 split seemed good enough, it makes it easier to dicsciminate between user and kernel addresses, the difference between 2GB and 3GB is not that high (about a year in my restatement of Moore's law "a bit of address space every 18 months"), and Microsoft values backward compatibility higher than Linux does.
But this extra 1GB, that Mac OS X's 4GB/4GB split has over a 3GB/1GB split, is very costly as it forces a page table switch for each syscall. This is extra overhead that Linux doesn't have. Ingo Molnar, who developed a 4GB/4GB patch for Linux, explained this performance hit: http://lwn.net/Articles/39283/
This reinforces the fact that Linux's choice seems to be the better tradeoff between what Windows and Mac OS X do.
"One of the adverse consequences of the /3GB switch is that it forces the kernel to operate inside a much smaller space.
One of the biggest casualties of the limited address space is the video driver. To manage the memory on the video card, the driver needs to be able to address it, and the apertures required are typically quite large. When the video driver requests a 256MB aperture, the call is likely to fail since there simply isn't that much address space available to spare."
"The NVIDIA kernel module requires portions of the kernel's virtual address space for each GPU and for certain memory allocations. If no more than 128MB are available to the kernel and device drivers at boot time, the NVIDIA kernel module may be unable to initialize all GPUs, or fail memory allocations"
Yes there is a workaround: use the vmalloc=xxx parameter to increase it to a value greater than 128MB. This will work in most cases where the reserved virtual space can almost always at least be increased up to 256MB. I had to use this parameter myself 7 years ago when I was running 50-100 QEMU VMs on a 32-bit host with 32GB RAM and PAE.
The only cases where vmalloc=xxx won't solve your virtual address space is in exceedingly rare software/hardware configuration (more than 100+ QEMU VMs, more than probably about 4 Nvidia GPUs since they seem to use ~64MB each).
So all in all, yes for 99%+ of users not running these rare configs, the 3GB/1GB split is just fine. Which is why Linux never changed this default. Microsoft has more problem with a 3GB/1GB split because their kernel is less space-optimized (mostly due to bad coding practices because too many Windows drivers/kernel developers assume that 2GB is available.) I maintain my opinion that 3GB/1GB is a better tradeoff.
Seriously: there are trade offs everywhere. Initially, a 2/2 split seemed good enough, it makes it easier to dicsciminate between user and kernel addresses, the difference between 2GB and 3GB is not that high (about a year in my restatement of Moore's law "a bit of address space every 18 months"), and Microsoft values backward compatibility higher than Linux does.