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 > [email protected] > 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. -- edubuntu-users mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
