How to disable/limit pixmap cache in X

Gavin McCullagh gmccullagh at
Thu Sep 20 01:32:14 PDT 2007


On Thu, 20 Sep 2007, Carsten Haitzler wrote:

> On Wed, 19 Sep 2007 17:08:22 +0100 Gavin McCullagh <gmccullagh at>

> > I'm not an expert in X, so please excuse (and feel free to correct) me if I
> > have read this situation wrong.  In the same sense as a web client should
> > never be able to crash a web server, surely an X client should not be able
> > to crash an X server?  I would have thought for the sake of the X server
> > and its user, it should be able to prevent a client from using arbitrary
> > amounts of memory.  Perhaps this is my idealistic or even wrong point of
> > view?
> correct - but you didn't account for linux's default mdoe of optimistic
> allocation and mr. OOM killer. linux will return memory regions even if there
> is not enough to survive the request - assuming you don't actually use it all.
> you can tune this off and it should begin to help- then when you are out of
> memory you actually get a NULL back from malloc etc. and then - if the code is
> good, it can handle the null return and "unwind" safely. the problem is the
> over-allocation by default that makes any attempt to handle NULL properly a
> moot point.

This is something we can try out and possibly suggest to the LTSP guys.
Thanks for explaining.

> nb - storing them in client memory and using ximages as a delivery mechanism
> for drawing as opposed to pixmaps will MASSIVELY increase your network
> bandwidth usage and slow things down a lot. pximaps live in the xserver - and
> if possible in video ram. this means theory are fast to access, only need to
> be generated/uploaded when first "created" or modified, not on every redraw of
> the window.

Fair enough.  This is mostly an issue for the firefox guys though.  Opera
and Konqueror seem to be able to deal with heavy-graphics webpages without
sending xrestop off the scale.  Perhaps in doing so they use much higher
bandwidth.  On a local GigE network, it might not be an issue of course.


More information about the xorg mailing list