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>
> 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.
> 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
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster at rasterman.com
Tokyo, Japan (東京 日本)
More information about the xorg