Firefox Granparadiso + Patch and tweak

[Jim McQuillan]

Gavin,

Great stuff.  Thanks for getting the info and summarizing it.

This all leads me to believe that the Xclient applications just need to 
behave better than they do.

Firefox loads up a page from a website.  Each image on the page gets 
sent to the Xserver in anticipation of being needed soon.  Even if the 
user never scrolls the page down to the point where the images are 
exposed.  Also, if you are on a page, and you click a link on the page, 
the images from the first page stay in the Xserver, with the 
anticipation that you might click the Back-button and return to the page.

It sounds like the patch from Federico helps this.  Although I haven't 
had a chance to look at it yet, to see how it does this.

Have we gotten the attention from anyone in the Firefox world to help us 
out?

Maybe we could have a meeting about this at UDS in Boston.

Thanks,
Jim McQuillan
jam at Ltsp.org




Gavin McCullagh wrote:
> Hi,
> 
> 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.
> 
> 	http://lists.freedesktop.org/archives/xorg/2007-September/thread.html#28452
> 
> 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.
> 	http://lists.freedesktop.org/archives/xorg/2007-September/028481.html
> 
> 2. Pass -ld, -lf and -ls options to X when starting it.  This limits the
>    overall data allocation X will try.
> 	http://lists.freedesktop.org/archives/xorg/2007-September/028477.html
> 
> 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.
> 	http://lists.freedesktop.org/archives/xorg/2007-September/028474.html
> 	http://lists.freedesktop.org/archives/xorg/2007-September/028484.html
> 
> 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.
> 	http://lists.freedesktop.org/archives/xorg/2007-September/028478.html
> 	http://lists.freedesktop.org/archives/xorg/2007-September/028490.html
> 
> 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
> instructions?  
> 
> Gavin
> 
>