On Sun, 26 Aug 2012 11:15:09 +1000 David Seikel <onef...@gmail.com> said:
> I leave my E17 CPUfreq module configured with "Set CPU power policy" on > "Automatic", "Powersaving behaviour" on "Automatic" and it does what I > think you want with no issues. > > The difference between what you stated you want and what actually > happens is that the frequency drops when ever the entire system is > idle, not just when E17 is idle. So more power is saved overall. Most > of the time I'm using my computer I'm not actually giving E17 anything > to do, I'm focused on some applications window or another. So slowing > down when E17 is idle means it would slow down right when I want to use > it. I don't think that's what you want. > > BTW, the ARM in my phone has 18 CPU frequencies it can run at, though I > suspect that's just the number of entries shown in the app I use and it > can do more. I understand that the pegasusq governor (not ondemand) is > often used on Android phones for keeping the battery life long while > also being responsive and performant when needed. It's what I use and > again, no issues. indeed this is a kernel cpu governor issue. by having e "work around it" we're avoiding the real fix. but is there a better way to do this? as such i almost always use "low power automatic" or "automatic" unless benchmarking... almost always... except i have definitely noticed speedups to compiling if i stick it at "maximum speed", and of course benchmarks get affected heavily by it - i've seen it, so i need maximum power then. this is probably just a matter of poor responsiveness by the kernel governor (not clocking up quickly enough) and a new governor that always clocks up to full speed with a much lower threshold (e.g. watch active timeslices and if any single cpu core's timeslots are more than 80% full for just 1ms, then clock up to full - problem. if 2 procs on 2 cores ping-pong then it misses this and the ping-pongs are too slow. i need to think about that). now to e's "userspace powersaving features"... the reason e has the "suspend on blank" feature is it is something that the kernel doesn't do and it highly affects the user - a suspended machine is totally inactive and takes a while to wakeup, but it is a much lower power state. this isn't a power saving feature, but e also can raise/lower nice value of processes owning windows based on focus. if you use ondemand or automatic the cpu should mostly stay clocked down while blanked unless you leave stuff running (apps doing processing etc.) and it will clock up and down as needed here while the screen is blank. reality is though... apps tend not to care and will go do this anyway (leave browser on and it will happily keep running jquery animations all day long while blanked :)). so here's the catch. the kernel doesn't have any idea about the user and responsiveness for the user or if the user is paying attention to performance. at this stage i know of now way to tell it "responsiveness is the most important thing right now so do that" vs "responsiveness is irrelevant to focus on saving power" OTHER than changing governors from userspace. when the screen is blanked we are in the latter state, and when it's not we are in the former. reality is that today ondemand and automatic are close to being fine, but not quite. they don't seem to clock up fast enough to keep things like compiling fast, and they still clock up even when a user is not there (since you probably use the same base power load here anyway, it's better to stay clocked down). so as i see it, reality is we need to tell the kernel information on what kind of response scenario a user would expect... and right now the only way is to go swizzling with governor. p.s. we ultimately need to do this for mobile purposes. minimized apps (for illume this means all apps that are not visible) should literally be SIGSTOPed while in the background (unless they specifically hint that they must keep running). efl (elm) should also realize the process has no "active" windows and use ecore_throttle to throttle itself. maybe suspend rendering to windows/canvases and use the evas_dump infra to free up memory etc. so there is much more we need to do for resource (power, cpu, memory) saving outside of the kernel. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
