Session suspension and restoration protocol

[Michel Dänzer]

On 2018-06-19 02:22 PM, Simon McVittie wrote:
> 
> This indirect launching also avoids doing a fork-and-exec in the
> compositor or session manager, which can be problematic under low-memory
> conditions: the kernel needs to allocate enough virtual memory space for
> a second copy of the parent process (even though the physical memory that
> backs it is going to be copy-on-write, and in fork-and-exec it only exists
> briefly and is mostly unmodified), and when a compositor has your GPU's
> address space mmapped, that's actually a significant practical problem.
> I think Endless have had trouble with this in GNOME Shell on 32-bit -
> there's easily enough address space to have the GPU mmapped once, but
> if GNOME Shell does a fork-and-exec, the child process briefly has the
> GPU mmapped for a second time, and there isn't always enough address
> space free to do that.

FWIW, /dev/dri/* files are supposed to be always opened with O_CLOEXEC,
to prevent the file descriptors from leaking to children. There were
bugs in libdrm meaning this didn't always happen, but those are fixed in
current upstream.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer