Re: [e-users] E, xscreensaver, and memory issues

[Larry Wyble]

On Tue, 16 Feb 2016 10:42:35 +0900
Carsten Haitzler (The Rasterman)  wrote:

> On Mon, 15 Feb 2016 08:10:45 -0500 Conrad Knight
>  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 

Re: [e-users] E, xscreensaver, and memory issues

[The Rasterman]

On Tue, 16 Feb 2016 18:49:44 +0100 Davide Andreoli 
said:

> 2016-02-16 2:42 GMT+01:00 Carsten Haitzler :
> 
> > On Mon, 15 Feb 2016 08:10:45 -0500 Conrad Knight 
> > 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 

Re: [e-users] E, xscreensaver, and memory issues

[Davide Andreoli]

2016-02-16 2:42 GMT+01:00 Carsten Haitzler :

> On Mon, 15 Feb 2016 08:10:45 -0500 Conrad Knight 
> 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?



>
> > 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 

Re: [e-users] E, xscreensaver, and memory issues

[The Rasterman]

On Mon, 15 Feb 2016 08:10:45 -0500 Conrad Knight  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. :)

> 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=/4140
___
enlightenment-users mailing list

[e-users] E, xscreensaver, and memory issues

[Conrad Knight]

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.

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.

Thanks,
-Conrad.

-- 
Whenever and  wherever you want.

--
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=/4140
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users