Firefox Granparadiso + Patch and tweak

[Jim Kronebusch]

Excellent summary Gavin.  I have to admit I don't know how to implement any of the
suggestions, at least not yet.  I also don't know enough to know if any of the
suggestions are of any merit.  But at least suggestions are flying around, which to me
is an improvement in itself.  I did receive a shim code from Brian Paul last night that
can be preloaded and does effectively monitor pixmap usage and kills the offending app
if it exceeds a pre-set limit.  This isn't pretty, but it does provide a safety net to
keep clients running.  However Jim M informed me that this method is a pretty ugly hack.
 If anyone wants to see it I'll send it over.  I tested it last night and was able to
set a limit to 20MB and if pixmap usage exceeded 20MB the application that requested to
exceed the limit was killed.  

My hope is that these threads spark discussions that can simply be looked over by those
with far more knowledge of the situation than myself (such as Gavin and Jim).  I just
can't believe that as large of a problem this seems it could be/is that there isn't more
discussion on it.  But I am quickly seeing that this is because those ultimately
responsible for a fix (such as Xorg, Firefox, OpenOffice) don't really see this as their
problem.  But what I see is the developers from these apps writing code that has the
possibility to make Linux as a whole unstable for end users, which is not good.

I assumed that Federico was an active developer for Firefox, so I guess I thought we
finally had their attention, maybe I'm wrong.  I did post back out to the bug this
morning asking if the section that sets discard times (as Gavin pointed out) could be
made smarter.  Since it appears this really could be a possible fix for Firefox, it
would be nice to improve it and not use a hard set limit.  I asked if it was possible to
code this section to monitor overall RAM usage, and set the limit accordingly.  Say if
RAM usage is less than 15% set the discard timer at 10 seconds, if usage is at 50% set
it to 5 seconds, if at 80% set it to .2 seconds.  This may not be at all feasible, but
if it is, this could provide increased speed and performance as intended on systems with
plenty of RAM, but on lower RAM systems or where RAM use becomes heavy, the discard
timer would self adjust and sacrifice performance for stability.  We'll see what he
posts back.  I have also not received word yet on the possibility of a backport for this
patch to 2.x.

Jim 

On Thu, 20 Sep 2007 09:58:45 +0100, 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
> 
> -- 
> edubuntu-users mailing list
> edubuntu-users at lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by the Cotter Technology 
> Department, and is believed to be clean.


Jim Kronebusch
Cotter Tech Department
453-5188


-- 
This message has been scanned for viruses and
dangerous content by the Cotter Technology 
Department, and is believed to be clean.