On Thu, 21 Sep 2017 08:17:53 -0700 Marc MERLIN <marc_...@merlins.org> said:
> On Tue, Sep 19, 2017 at 10:48:19PM +0900, Carsten Haitzler wrote: > > > I'm just about ready to downgrade back to 0.18.6, I can't have a WM that > > > sucks so much CPU and battery. > > > > > > Any idea what could be causing this and how to get around it? > > > > could be many things. what else is waking up? didn't you just have drm vsync > > issues? could possibly still be happening. here is what i see: > > Damn, that's low. > More output from my (big) laptop: > The battery reports a discharge rate of 24.4 W > The estimated remaining time is 3 hours, 19 minutes > > Summary: 1614.5 wakeups/second, 61.1 GPU ops/seconds, 0.0 VFS ops/sec and > 53.0% CPU use > > Power est. Usage Events/s Category Description > 7.42 W 100.0% Device Display backlight > 5.50 W 25.8 ms/s 413.7 Process /usr/bin/enlightenment > 4.25 W 9.2 ms/s 307.0 Timer tick_sched_timer > 3.10 W 11.7 ms/s 224.0 Timer hrtimer_wakeup > 2.01 W 26.4 pkts/s Device Network interface: > wlan0 (iwlwifi) 1.91 W 100.0% Device USB > device: usb-device-0765-5010 > > But big laptop or not (4K screen, IGP), 413.7 is the most wakeups of anything > on my system. > > Well, how about this: > The very next morning, I changed absolutely nothing, and when coming > back from sleep I'm now seeing: > 1.22 W 13.8 ms/s 133.0 Process /usr/bin/enlightenment > 272 mW 11.4 ms/s 30.6 Process /usr/bin/enlightenment > 239 mW 6.1 ms/s 27.3 Process /usr/bin/enlightenment > > Looks like whatever I hit, it fixed/gone for now. > > Or is it? While typing this Email bit, it went back up to: > 2.15 W 27.4 ms/s 308.6 Process /usr/bin/enlightenment > 2.50 W 20.1 ms/s 346.2 Process /usr/bin/enlightenment > 2.49 W 36.7 ms/s 325.2 Process /usr/bin/enlightenment > > What could be causing so much variance? > > Oh my, it seems that running xmms2 (0.8+dfsg-4) causes the music title > to scroll, and that's enough to cause e21 to wake up a *lot* > killall -STOP xmms fixed it it seems: > 410 mW 9.2 ms/s 60.1 Process /usr/bin/enlightenment > 359 mW 7.3 ms/s 55.1 Process /usr/bin/enlightenment oh... thats why i mentioned apps updating/rendering. yes. a scolling title means e will be getting damage events from the app and have to re-composite parts of the screen... any compositing wm will have to do exactly the same thing. compositing involves waking up the ap, xserver and wm. e will wake up more than "once per frame" because as i mentioned it'll get the damage event, realize it's not a vsync frame tick wakeup, go back to sleep and wait for the next vsync tick, then when that happens kick off a frame render. so thats why just number of wakeups isn't the best measure. my numbers above had an idle screen. no blinking cursors or scrolling titles... > > so basically it's fine. there is some polling of cpu freq and > > temperature, some battery notifications.... but really its quick > > wake and sleep as any render will invariably involve deferring the > > rendering for the next vsync. stracing shows e asleep for most of a > > second and eeze is forcing a poll every second on the temperature > > sensor. i unload temperature module and e will stay asleep for 2-3 > > or 4 secs at a time then wakeup to a battery/power supply event and > > go check battery status. ymmv based on your acpi dsdt and how often > > battery acpi events happen, but the wakeups you see above are really > > only like 1 or 2 per sec. i think it's counting a blocking syscall > > like a read() of a /sysfs node or a write+read from pipe (vsync event > > from vsync thread to mainloop), actually strace e with timestamps and > > see. it may be counting selects that in the loop run "poll to see if > > events came in while we were reading them" or the thread selects etc. > > so take that number of wakeups with a grain of salt. > > Removing the battery widget did not help. well removing it won't help. unloading the battery module might. > > FYI i had my GPD pocket 7 (my mini 7" baytrail laptop) run for 22hrs > > without suspending (screen on lowest brightness level, wifi connected)... e > > of course running. when e is animating expect a lot of wakeups - at least > > 2-3 maybe 4x the actual framerate due to the above (the wake it's > > measured). another sample of battery life: galaxy book 12, 50% brightness > > with e just idling: > > I'm very jaleous now :) > > > So... actually look into what is waking things up. fast polling times for > > gadgets like temp, cpufreq etc. will use more power. temperature if using > > udev (eeze) can wake up more often. > > > > if you have terminals with blinking cursors... that's not going to help > > much... disable blinking. :) > > I have none of this. you have a scrolling xmms title. apps updating their windows. that's going to suck for battery life no matter how you slice or dice it and it's going to force wakeups. > Thanks for your reply. > Marc > -- > "A mouse is a device used to point at the xterm you want to type in" - A.S.R. > Microsoft is to operating systems .... > .... what McDonalds is to gourmet > cooking Home page: http://marc.merlins.org/ | PGP > 1024R/763BE901 > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
