On Tue, 16 Feb 2016 10:42:35 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> On Mon, 15 Feb 2016 08:10:45 -0500 Conrad Knight > <iestynap...@gmail.com> said: > > > Hi, > > > > I wrote a while back about an apparent memory leak while running > > Enlightenment, but only have time to look into it every few weeks. > > Here is something I've found... > > > > The run-away memory usage only occurs while xscreensaver is running, > > and then not every time. I figured it might have to do with specific > > modes of the screensaver (i have it set to cycle through them > > randomly). A few quick tests found one that reliably causes memory > > usage to spike, "zoom", the last hack (in xscreensaver parlance) in > > the list for the random selections. > > > > These "hacks" can also be run manually without the xscreensaver > > executable, and i was able to verify that "zoom" run by itself in a > > window very quickly caused the memory problem. I had to switch to a > > text virtual terminal to kill the process. Even after this, "ps" > > shows that enlightenment continues to use over 40% of my system's > > memory. > > so THAT is useful info. it's caused by xscreensaver. > > first advice - stop using it. i haven't used it for like 15 years. its > pointless chewing up your cpu (and gpu) while you are NOT THERE. it > just eats power, damages our environment (by causing more energy use > and thus attendant fossil fuel usage to generate it - in general. yes > we can get into "but my power mostly comes from renewables" but then > it'd help unload that and lower investment costs) ... and it costs > money. ROFLMAO .. My thoughts exactly. (; > screensavers are a hold-over from the days where monitors couldn't > shut off - if you displayed the same thing for a long time it'd burn > the image in. then monitors were able to actually power down later > saving power. a black screen still used power. it hasnt needed to use > power for like 2 decades now. > > so stop using screensavers. you're not there. > > now i'm done with that rant ... the issue is one of events. > > http://devs.enlightenment.org/~raster/massif-out.txt > > put that through massif visualizer and see. the issue is partly that > xlib itself uses huge amounts of ram to buffer incoming event info - > specifically region info then ecore puts this region info on its own > event queue and uses yet more ram. > > so let's look at this in more detail. zoom actually uses really low > level draws > - like drawing individual points or tiny regions. every one of these > draws causes an update (damage) event from x and we store the tine > region - i haven't looked but i think they are on the magnitude of > 1x1 pixel or so. and its generating millions and millions of these > every second. just to remember that little rect consumes somewhere > like ~16 bytes of memory or more. so imagine like 10, 20, 30 million > bytes.. or 10-30mb per second are easily being eaten up to store all > of these. > > at least what i see under valgrind and just running plain.. e can't > keep up with the MASSIVE flood of incoming tiny damage regions and is > basically spending all it's time dealing with this, never going idle. > it's a horrible situation that basically never happens normally > except for these patholigical apps that want to draw pixel-by-pixel > with "old school 2d x11 draw primitves". > > so ok - this is a nasty client when it comes to compositing in the > way it draws. xorg doesnt seem to try and do any damage region > "merging" inside, so the compositor has to deal with it all and > that's just a tough thing to do. > > but this does seem to point out a few little issues that wouldn't > normally turn up. i'll poke into some of them. but for now - just > stop using xscreensaver. this os likely one of those things that will > go away as we eventually move to wayland .. as it just wont exist > anymore. :) > > > I can kind of see why the memory usage of a badly behaving program > > (or is it my video driver?) would show up as being used by > > enlightenment instead -- enlightenment has to actually display the > > pretty graphics on the screen. But why, after the process has been > > killed, is this memory not freed? And is there perhaps a compile > > option for E (or xscreensaver, for that matter) that would prevent > > all of this in the first place? > > > > Side note: "enlightenment_remote -restart" does free up the memory, > > but often this times out before the restart occurs. Also, the > > restart triggers the not-remembering-size-or-location problem with > > the clock module, a separate issue that has persisted into e20. > > ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
