How to disable/limit pixmap cache in X

[Carsten Haitzler (The Rasterman)]

On Thu, 20 Sep 2007 10:16:31 +0100 Gavin McCullagh <gmccullagh at gmail.com>
babbled:

> 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?

yeah. significantly mroe complex than tcp. what we need is a higher level
pixmap manager daemon - much like font glyphs. an app provides an image with a
url and some form of hash id/timestamp. all other clients asking for the same
resoruce (url+timestamp//hash) share the same source pixmap. it's read-only
(need to add extensions for this in x) once created and made public. refcounted
from there. this will allow such a cache manager to actually have a global
pixamp usage policy for an x display and limit pixmap usage to a certain size
and re-generate pixmaps as needed from source (if it knows how) or when a
pixmap is out of cache and a client asks for the pixmap again the client is
told to upload it etc. - anyway. the end result is centralised control over a
common and large resource. this wouldn't cover pixmaps used for temporary
drawing - i.e. "private" pixmaps, but it would cover:

pixmaps for theme and widget elements
wallpapers
icons
images in web pages
filemanager icons/thumbnails

etc. i.e. any "image" that is generated from source data that is invariably
some form of file source.

> 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?

invariably i'd expect a wm to be one of the best behaved X apps out there so
i'd keep it out of the picture (it will be trapping x errors, and playing nice
- because it has to as it's always there).

> > 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
> 
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)