Firefox Granparadiso + Patch and tweak

Gavin McCullagh gmccullagh at
Thu Sep 20 09:58:45 BST 2007


On Wed, 19 Sep 2007, Jim Kronebusch wrote:

> So now I am hammering on xorg to get a fix to limit the amount of RAM
> available for pixmap storage (I was slammed on the list stating pixmaps
> are not cached but stored).  This may be a better workaround than
> limiting RAM usage in general.  I doubt it will go anywhere.  But at
> least if that was done client stability could be fairly stable and if an
> app lost stability then that could be dealt with on more reasonable
> timeline.

An interesting discussion has started on xorg.

A couple of simple suggestions that can easily be tried are:

1. Turn off overcommit in linux:
	echo 2 > /proc/sys/vm/overcommit_memory
   may help ease the problem, though it looks like it won't fix it.

2. Pass -ld, -lf and -ls options to X when starting it.  This limits the
   overall data allocation X will try.

either of which, if effective, could presumably be added to LTSP without
too much trouble.

Other suggestions include hacking xrestop to watch the ram usage of x
clients and kill where necessary, though some people have raised issues
with that.

It would seem that the problem has a far more difficult one underlying it.
X clients don't know how much memory is available and so they can only ask
for as much as they need and see do they get it.  The X server doesn't know
in advance how many windows and pixmaps there will be, so it can currently
only respond by allocating space until it runs out.  The next client to
make a request then gets refused.  However, that could be any client,
including the window manager.

So I guess on Jim's thin clients, the X server allocates almost everything
to firefox, which doesn't let go of it.  Then, once you're out of RAM, you
can't go any further.  The linux oom killer could kill X of course, but
that's not ideal either.  

Jim: do you know how to try out [1] and [2] or should we give some


More information about the edubuntu-users mailing list