Ondrej Valousek wrote: >> There's already a bug on this. I opened it a couple of years ago. >> >> https://bugs.freedesktop.org/show_bug.cgi?id=4942 >> >> But, what's the Xserver to do? Deny allocating any ram to the Xclient? >> that's what the XRAMPERC does. >> > > I 100% agree with Jim but I however do not 100% agree with the bug > subject he referenced. > Bottom line is that Xorg does not currently have a way to limit its RAM > demands, but we do have a perfectly working solution for this - so why > should the X developers waste their time implementing something we > already have? > > I must agree with the comment #2 for the bug above - Xorg should rather > implement some "quota" RAM limit per Xclient. As Jim already spotted, > when we limit the whole X, the session is substantially more stable. But > it can still happen, that your gnome session, requesting only a small > piece of X server memory, will be denied and will eventually crash. With > the quota system it could never happen - you would let every single X > client to allocate some amount of resources and here you go...
I agree, but it's not that easy. Different applications really need different amounts of resources from the Xserver. On a freshly booted system, when you log into a Gnome session, right off the bat, you have about 20 Xclient programs running. Maybe it doesn't seem like 20, but if you run xrestop, you'll see each one. The Gnome panels are each separate Xclients, the mixer applet, trashcan, screensaver, window manager are all X clients. So, do you say that "No single Xclient can grab more than 5%"? Surely Firefox would crash before it gets a chance to display anything. Maybe we could say that "no single app can allocate more than 75% of ram", and then *hope* that they all play nice. I think if app developers would just stop assuming that they are the ONLY application that is important, and if they'd pay attention to error codes returned when they make a system call or X request, and fall back to a reasonable state, rather than die, things would be alot better. Jim McQuillan [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
