How to disable/limit pixmap cache in X
Gavin McCullagh
gmccullagh at gmail.com
Thu Sep 20 01:32:14 PDT 2007
Hi,
On Thu, 20 Sep 2007, Carsten Haitzler wrote:
> On Wed, 19 Sep 2007 17:08:22 +0100 Gavin McCullagh <gmccullagh at gmail.com>
> > 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.
Gavin
More information about the xorg
mailing list