It is an useful feature for systems which are using (...still have to use) 32-bit binaries, and the 4G limit came into consideration.
It essentially means, that the 32-bit user-space code, the 32-bit user-space data and the (32-bit with PAE, or 64-bit) kernel live in different address spaces, which essentially enables for the processes to use nearly all of the possible maximal 4G address space for their data.
Except some ancient announcements, unfortunately I couldn't find from it any more:
I am pleased to announce the first public release of the "4GB/4GB VM split" patch, for the 2.5.74 Linux kernel:
http://redhat.com/~mingo/4g-patches/4g-2.5.74-F8
The 4G/4G split feature is primarily intended for large-RAM x86 systems, which want to (or have to) get more kernel/user VM, at the expense of per-syscall TLB-flush overhead.
On x86, the total amount of virtual memory - as we all know - is limited to 4GB. Of this total 4GB VM, userspace uses 3GB (0x00000000-0xbfffffff), the kernel uses 1GB (0xc0000000-0xffffffff). This is VM scheme is called the 3/1 split. This split works perfecly fine up until 1 GB of RAM - and it works adequately well even after that, due to 'highmem', which moves various larger caches (and objects) into the high memory area.
On my tests, some of my processes start to dying roughly at 2-3 GB.
How could I do achieve this? I use a relative recent kernel (4.10). I can use a 64-bit kernel on a 32-bit user space or use a 32-bit PAE kernel.
It is enough, if only some of the processes use 4G/4G, but they seem to really need it.