How to disable/limit pixmap cache in X

Carsten Haitzler (The Rasterman) raster at rasterman.com
Wed Sep 19 15:59:36 PDT 2007


On Wed, 19 Sep 2007 10:08:37 -0500 "Jim Kronebusch" <jim at winonacotter.org>
babbled:

> On Wed, 19 Sep 2007 11:34:19 +0300, Daniel Stone wrote
> > On Tue, Sep 18, 2007 at 10:02:17PM -0500, Jim Kronebusch wrote:
> > > It appears that the ability to cache pixmaps to RAM is not a necessity
> > > and rather a feature to help speed up image access.  So I joined this
> > > list to see if anyone knows of a way to say limit in X the amount of
> > > pixmap storage available to applications, or how to even prevent them
> > > from caching pixmaps at all.
> > 
> > Um.  If someone says 'put this image into a window', you need to know
> > _which image to put_, which requires the server to store the pixmap, at
> > least temporarily.  If this is undesirable, you could patch the
> > applications to just free the pixmaps as soon as they're done using
> > them, or (in Firefox's case), just to not leak gigabytes of the bloody
> > things.
> > 
> > Limiting pixmap storage will mean your apps will just get horribly
> > confused and exit immediately, which is probably not what you want.
> > 
> > So, either way, the answer comes down to 'look at the app'.  (Or, 'don't
> > use Firefox'.)
> 
> This problem isn't just related to Firefox (although it appears to be the
> worst offender).  OpenOffice has trouble as well coming in a close second
> depending on what you are doing in it (typing a letter obviously is not a
> problem).  And various other apps do this to some degree as well.
> 
> The problem in the thin client world is that when an app runs wild with
> pixmaps it is possible to chew up all available RAM.  This in turn hard
> freezes thin clients.

X has a command-line option for this. Several actually:

-ld int                limit data space to N Kb
-lf int                limit number of open files to N
-ls int                limit stack space to N Kb

note this limits data allocation as a whole - so not just pixmaps (which is
what you want really as other data does take space - windows, GC's etc. too). i
would repeat what others have said. doing this can and will impact apps.
either they will crash or just behave totally strangely - very few, if any
actually catch x errors and then trace the error (as it's async) and have a
code path to deal with running out of resources. it's just too much work.

> So even though it is not good practice and can cause apps to crash, I am
> looking for a way to limit how much RAM can be used for the purpose of
> storing pixmap data.  If such a setting was available an offending
> application may simply die a horrible death, but at least the client itself
> can still function without requiring a hard reboot and loss of data in other
> open applications.
> 
> This would be a band-aid to keep thin clients running until a method is found
> to work with the offending applications.  Problem is there are so many apps
> there needs to be a way to set a limit, then if apps start crashing we can
> track down their devels and try to get a fix into the app.  I realize this
> isn't a real problem for full desktops, but please understand how big of a
> deal this is for the usability of Linux Thin clients.
> 
> Jim
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by the Cotter Technology 
> Department, and is believed to be clean.
> 
> _______________________________________________
> 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 (東京 日本)



More information about the xorg mailing list