> As for your comment about thinking this is an Xorg problem. I sort of > agree/disagree. > > I think it's a problem in the interface BETWEEN the Xserver and the > Xclients. > > The Xserver needs to be able to refuse requests for pixmap allocation, > and the Xclients need to pay attention to that refusal and gracefully > handle it. Right now, we are limiting pixmap allocation by setting > X_RAMPERC. the problem is, the Xclients die a horrible death when they > don't get what they want from the Xserver.
Let me try and get a little better understanding here (forgive me if what I ask doesn't make sense). It seems that if pixmap caching to system memory was restricted specifically the applications would maybe still run upon refusal of a pixmap cache request, but have more of a delay in displaying the graphic when called on. However the X_RAMPERC option limits the application to use of RAM in general and when it hits the limit it then dies a horrible death. So if there was some method to split these two apart things may behave in a more tolerable fashion? Would Firefox still then be free to hog as much RAM and SWAP as it could get it's grubby hands on for basic operation but then be told by some new option to back off on the caching of pixmaps, or are the two inseparable? It seems that most every scenario where the clients are freezing in most every application are due solely to excessive pixmap caching either by a single app or a combination of apps used simultaneously. Is it conceivable that an option could be available in xorg.conf that limited pixmap caching to 32MB max (user configurable to increase/decrease as desired), or maybe have an option in lts.conf to pass this to X but still leave memory use unrestricted for everything but pixmaps? (lts.conf stuff would of course start with X having this capability) This may be the route I try to take when I start posting to the xorg devel list. Of course they may very accurately respond telling me I'm crazy. Another thing I played with today when monitoring pixmap cache from within OpenOffice, insert a handful of graphics into a Writer document, open xrestop to monitor usage, then scroll back and forth over the the graphics and watch pixmap cache climb. I was able to insert 4 images into Writer and only consume 8MB of cache with pixmaps, but upon repetitive scrolling and no other changes increase Writers pixmap cache to 155MB. Something this stupid would be enough to freeze a client with 128MB RAM (silly thing to do but I am amazed everyday at the stupid things people do). I find it odd that Writer doesn't just cache the image once and then draw from it, it keeps caching the same info over and over again....seems like just bad programming to me. So if there was a setting to limit only pixmap caching we could still see a performance increase at first, but then if an application got greedy or just plain stupid, it would get cut off, but still be allow full use of RAM and SWAP to keep critical processes running. Thoughts? -- This message has been scanned for viruses and dangerous content by the Cotter Technology Department, and is believed to be clean. -- edubuntu-devel mailing list edubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-devel
