[Linaro-mm-sig] Memory Management Discussion

[rmorell at nvidia.com]

On Wed, Apr 20, 2011 at 05:23:18AM -0700, Tom Cooksey wrote:
> 
> I guess the bottleneck will probably be the window compositor, as it will
> need to have a reference to all window back buffers in the system. So, do
> any of the DRI folks have any idea how many windows (with back buffers) a
> typical desktop session has? Do minimised windows have back buffers
> allocated in X11?

In a traditional X11 composited environment, all top-level window front
buffers are redirected offscreen to their own memory (not only back
buffers).

> Even if there were as many as 100 top-level windows (which seems excessive),
> each triple-buffered, that's still pretty far from the 1024 limit?

If the process doing the compositing is the X server itself (rather than
a direct-rendering compositing window manger), there is already file
handle pressure, due to each client connection consuming a socket, plus
all of the device nodes needed to open for input and output.  If each
client conservatively creates only one window, then we hit the limit at
less than 512 clients.  (Throw in a few clients like the gimp that
create a whole bunch of top-level windows and you use them up more
quickly.)

Admittedly, the default compile-time MAXCLIENTS in the server right now
is 256, but, e.g., Red Hat has patched their servers since 2007 to bump
that to 512 [1], so presumably somebody is hitting the limit already and
uses more than 256.

I think somebody mentioned that the X server runs as root so it can just
change its ulimit, but I don't think that's a good argument since we're
actually trying to get away from X needing to be suid root.


[1] https://rhn.redhat.com/errata/RHBA-2007-0756.html

- Robert