On Tue, 16 Feb 2016 18:49:44 +0100 Davide Andreoli <d...@gurumeditation.it> said:
> 2016-02-16 2:42 GMT+01:00 Carsten Haitzler <ras...@rasterman.com>: > > > 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. > > > > 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. :) > > > > > just an idea to solve this in an easy way (maybe I miss something): > The xscreensaver is a fullscreen window, right? in that case there is an > option > in E to "unredirect fullscreen windows" (dunno if it's the correct english > name > of that option). Shoudn't that option fix the issue? it should also do it - but the issue happens if u run the saver by hand too: /usr/lib/xscreensaver/zoom :) i looked into it and there doesnt seem to be an easy/quick fix. there just seems to be an awful amount of damage event traffic and region traffic - even xlib itslef allocates massive buffers for send/receive - i saw the xlib request buffer balloon out to over 100mb. :( > > > 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. > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > > > ------------------------------------------------------------------------------ > > 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 > > > ------------------------------------------------------------------------------ > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
