How to disable/limit pixmap cache in X

[Gavin McCullagh]

Hi,

On Thu, 20 Sep 2007, Glynn Clements wrote:

> > On systems with overcommit (i.e., all of them), there's no way to tell.
> 
> Even on systems without overcommit, there's no way to tell how much
> memory you will need in the future for other clients (which is what I
> mean by "headroom").
> 
> If the server simply allows allocation so long as it can satisfy that
> particular allocation, you can end up allowing Firefox to consume 99%
> of available memory, then having to refuse a 1KiB allocation from a
> less "greedy" client.
> 
> It may be worth having "fair share" rules, limiting the amount of
> memory which can be used e.g. by a single client, or for pixmaps, or
> for pixmaps over a certain size, etc. IOW, push the consequences of
> greedy clients onto the clients in question, rather than onto
> whichever unlucky client makes an allocation at the wrong time.

So we're into a problem of allocating finite resources where some clients
apparently can have indefinite need.  

This is a little reminiscent of TCP congestion control, where the network
gives no information about available bandwidth, except by dropping packets.
TCP senders probe by linearly increasing their bandwidth usage over time,
until they detect a drop, then they reduce their usage (traditionally by
half) and begin increasing again.  This (with some buffering at routers)
allows the full (or almost full) bandwidth to be used, while allowing new
flows to start up and take their share of the bandwidth away from the
others.  It seems unlikely that you could get all X clients to implement
this though :-)

It seems that TCP is somewhat more constrained than X.  I presume this
problem also exists in the linux memory manager.   The xrestop hack sounds
similar to the oom killer?

On Thu, 20 Sep 2007, Glynn Clements wrote:

> The problem is quite clear. There are some potential workarounds which
> are feasible, e.g. a more intelligent allocation strategy (the current
> one is basically to try to honour every allocation). That would mean
> that Firefox' gluttony would only kill Firefox.

In particular, certain clients, such as the window manager should ideally
not be killed.  I would imagine for example that the oom killer doesn't
ever kill init?

> The more desirable behaviour, namely for applications to simply
> degrade in performance when resources are scarce, is something which
> has to be implemented in the application (or its toolkit).

Which is pretty much what TCP's congestion control does.

Gavin