Am 13.11.2018 um 19:46 schrieb Axel Davy <davyaxel0@gmail.com>:
I assume on windows, OpenGL, d3d, etc all allocate in the 2GB. Thus I believe most of the difference is the space taken by the mapped library codes (llvm, libx11, etc), and eventually some libraries allocating more space than they should (pulseaudio).

As far as I understand on Vista and later D3DPOOL_DEFAULT resources don't consume client address space as long as they stay in GPU memory. When they get paged out of the GPU, they reside in the app's address space.

I haven't written proper tests for this behavior, it is just what I inferred from application behavior. On Linux 3D drivers the behavior is similar, on MacOS the GL driver decides to keep a backup copy, and map GPU memory into application space, and not release any of that until you release the GL context. But Apple doesn't pretend to care about 32 bit any longer.

I don't see an easy way out of the problem. It'll be a mix of persuading Linux libs (pulseaudio) to use address space responsibly and don't pretend it is an abundant resource, persuading game vendors to set the LAA flag (although I think most of them do nowadays, if the games are still maintained) and hunting down waste in Wine (this has been an ongoing process since at least 10 years, I don't know if there are any easy bugs left).

If I understand correctly, windows maps some of its code onto the high 2GB, thus library code could be mapped there without bugs ?

I don't know of anything where that's the case, although I might be mistaken. Afaics the libraries themselves aren't big, it's the runtime allocations that are the problem. And as soon as we allow limited use of higher addresses, preventing them from leaking into the application will be rather difficult. E.g. in https://github.com/andrerh/hangover I allow Linux and Wine libs to load > 4GB for 32 bit processes. I ran into a problem where libpng passes a pointer to a static variable to windowscodecs, which in turn passes it to an application IStream method...