TR Forums

Thu Sep 08, 2016 3:12 pm

notfred wrote:
If you have head and tail and sed all in a pipeline then you could probably do the same thing with an inline awk pipeline.

Yeah, I know... never really got the hang of awk. My go-to tools for stuff like this are grep/head/tail/sed. Not necessarily optimal, but fewer things to remember so I can bang stuff out quickly.

BobbinThreadbare · Thu Sep 08, 2016 3:59 pm

just brew it! wrote:
BobbinThreadbare wrote:
That's some cool work, but I think dropping to powersave might be excessive. Conservative is going to keep your cores at low frequencies already.

Yeah, perhaps; and it did add the complication of needing to monitor load average to accommodate CPU-intensive background jobs. However, there was one specific scenario I had in mind when I did it -- the case where you've left a web browser up, and there's a badly coded page that pegs a CPU core. Even with the conservative governor that core will ramp up to full speed; with the support for powersave mode, that core will still get throttled down if you haven't touched the system for 15 minutes.

It is possible dropping all the way to powersave mode might cause stuttering issues for video playback, in which case the SECS_POWERSAVE value could be increased to a couple of hours (to accommodate full-length movies) if desired. Or disable powersave mode entirely by setting SECS_POWERSAVE to a very large value.

Also, a caveat I should've mentioned: Current Intel CPUs (Sandy Bridge and later, IIRC) use a different power management scheme, which probably won't work with this script. Indications are that Intel's power management does a decent job without further assistance anyway. So don't bother unless you're running Linux on AMD or an older Intel processor.

Do you not suspend your system? I suppose in that case you'd want to go down to lowest powerstate, but I'd prefer just using system suspend (which is already smart enough to know eg a video is playing).

Thu Sep 08, 2016 4:13 pm

I suspend laptops, but my desktop usually stays on. I sometimes access it remotely when I'm not at home.

Tue Sep 13, 2016 11:59 am

I've continued to play around with this a bit off and on. Yes, it has become a bit of a distraction; I guess the OCD side of me wants to see how well I can control CPU power usage without affecting perceived system responsiveness or performance.

I added some hysteresis to the threshold that disables the "powersave" governor to keep the system from hunting back and forth between "powersave" and "conservative".

I'm also experimenting with logic to completely idle extra cores (prohibit the scheduler from running anything on them) when system load is light; I'm trying to keep the number of active cores equal to roughly 2x the system load average. This should ensure there's ample headroom for spikes in demand, but cut power usage way back when the system sits idle for more than a few minutes. This does seem to have a clearly measurable effect; however I think I need a more responsive method of calculating load than the system-generated average; adding CPU cores back in when load rises takes way too long because the load average rises very slowly in response to increased CPU usage.

I'll post an updated version at some point...

SuperSpy · Tue Sep 13, 2016 12:35 pm

I'm just sitting here hoping you have a kill-a-watt plugged into your desktop...

Tue Sep 13, 2016 12:45 pm

SuperSpy wrote:
I'm just sitting here hoping you have a kill-a-watt plugged into your desktop...

Yeah, it occurred to me that total system draw would be interesting to look at too, in addition to what the CPU reports from the on-die power usage monitor. Expected behavior would reflect the delta in reported CPU usage, times a fudge factor (which I'm guesstimating would be around 1.3) for inefficiency in the PSU switcher and motherboard VRMs. I really need to verify this. Just haven't gotten around to digging up the Kill-A-Watt and putting it in the circuit yet.

Tue Sep 13, 2016 2:01 pm

So I went ahead and hooked up the Kill-A-Watt. No major surprises. It is difficult to correlate things accurately due to the readings bouncing around quite a bit, but assuming AMD's power monitoring is reasonably accurate, the CPU appears to account for about 40% of total system power draw when under light load, rising to around 60% at full load.

Light load (just the JACK audio stack and Amarok) - CPU 33W, system 85W
Moderate load (Chrome running with a couple of non-static web pages up, Amarok playing) - CPU 60W, system 105W
Heavy load (all 8 CPU cores pegged) - CPU 124W, system 203W

This is with my power tweaking script running, but the system was not left sitting long enough for it to activate the "powersave" governor. Maybe at some point I'll do some more in-depth measurement and analysis, both with and without the script. I do know that prior to this little exercise, I rarely saw the CPU power monitor report less than 50W under light load, and it was typically hovering around 60W.

Wed Sep 14, 2016 11:16 am

Modified it last night to use an explicitly calculated moving average of the number of running & runnable processes instead of the (system-calculated) 1 minute load average to decide how many cores to use. This allows scaling up/down of active core count to be much more responsive to system loading. Gonna run with this for a few days and see if I notice any lagginess. Haven't noticed any glitches/skips in multimedia playback so far, which was my biggest concern with doing this sort of thing.

Thu Sep 15, 2016 11:30 am

This I also learned: The active PFC in my PSU works very well. The Kill-A-Watt is indicating that the PF is between 0.97 and 1.0 over the entire range of system load.

SuperSpy · Thu Sep 15, 2016 12:12 pm

What model is it?

Thu Sep 15, 2016 2:07 pm

One of the Corsair CX series, I forget the wattage.

Mon Sep 19, 2016 9:01 pm

Hit the first serious snag. Dicking around with the CPU power state governor and/or core count on the fly completely destabilizes VirtualBox. Went to use my Windows VM tonight and it kept crashing, and eventually got corrupted to the point it wouldn't boot any more; I had to restore the VM image from a recent backup.

No time to investigate further right now, I just disabled my power management script for the time being. :-?

DrDominodog51 · Mon Sep 19, 2016 9:53 pm

just brew it! wrote:
Hit the first serious snag. Dicking around with the CPU power state governor and/or core count on the fly completely destabilizes VirtualBox. Went to use my Windows VM tonight and it kept crashing, and eventually got corrupted to the point it wouldn't boot any more; I had to restore the VM image from a recent backup.

No time to investigate further right now, I just disabled my power management script for the time being.

Perhaps you can change the script to check if a VirtualBox process is running and change the CPU to maximum performance + lower the polling rate while that process is running.

Mon Sep 19, 2016 10:10 pm

DrDominodog51 wrote:
just brew it! wrote:
Hit the first serious snag. Dicking around with the CPU power state governor and/or core count on the fly completely destabilizes VirtualBox. Went to use my Windows VM tonight and it kept crashing, and eventually got corrupted to the point it wouldn't boot any more; I had to restore the VM image from a recent backup.

No time to investigate further right now, I just disabled my power management script for the time being.

Perhaps you can change the script to check if a VirtualBox process is running and change the CPU to maximum performance + lower the polling rate while that process is running.

Yeah, I thought of doing that. I suspect the problem is with messing with the number of active cores (not the speed governor), but need to do some tests to verify that. If tests bear that out, then merely disabling the core enable/disable logic when VB is running ought to be sufficient.

Based on what I've seen these past few days, most (but not all) of the power savings seems to come from the governor tweaks anyway, since "disabling" a core doesn't really power it down, it just keeps the CPU scheduler from trying to use it.

I've already spent waaaaay more time than I intended on this... :lol:

Edit: I could easily imagine VB doing some sort of explicit affinity mapping of virtual to physical cores, then sh*tting the bed when the physical core one of the virtual cores is mapped to "goes away".

Edit 2: Perhaps anything that uses explicit core affinity is potentially vulnerable to this kind of (theorized) race condition. Ugh... down the rabbit hole we go.

DrDominodog51 · Mon Sep 19, 2016 10:45 pm

just brew it! wrote:
I've already spent waaaaay more time than I intended on this...

http://www.xkcd.com/196/

Mon Sep 19, 2016 11:04 pm

DrDominodog51 wrote:
just brew it! wrote:
I've already spent waaaaay more time than I intended on this...

http://www.xkcd.com/196/

LOL... yeah, I vaguely remember that XKCD. "Wait, just one more minute, I've got this... honest!" Been there, done that (though not during a hot date, sounds more like something I'd have said during a prototype demo).

Doubly hilarious given that monitor sleep/wake issues are still not an entirely solved problem in Linux, all these years later. (Though IME the problem generally goes the other way now, with the display randomly *not* turning off when it is supposed to, which is at least less annoying than having it cut out in the middle of something, requiring you to jiggle the mouse!)

Mon Sep 19, 2016 11:21 pm

just brew it! wrote:
LOL... yeah, I vaguely remember that XKCD.

The mouseover text on that one is one of Randall's best.

Tue Sep 20, 2016 9:15 am

Disabling individual cores seems to have minimal effect on power draw at the wall, even though the on-die CPU power sensor reports a non-trivial (20 watts give or take) drop in idle power usage when scaling back to a single core. So either the motherboard's VRMs and/or the PSU get very inefficient at extremely light loads (negating most of the CPU power savings), or AMD's CPU power sensor has issues.

Looks like I'll be removing the core enable/disable part of the logic (as I'm pretty sure that's what is hosing VirtualBox), and leaving just the dynamic switching of CPU governors.

Tue Sep 20, 2016 9:22 am

After looking more closely, I'm going with "on-die CPU power sensor is wonky". You'd think a 20W difference in power usage would make at least a small difference in core temperature, but it does not.

ludi · Fri Sep 23, 2016 4:47 pm

Assuming this info is correct, there's only one temperature sensor on that entire die and you're probably fighting a losing battle attempting to get useful information out of it.

Fri Sep 23, 2016 5:19 pm

ludi wrote:
Assuming this info is correct, there's only one temperature sensor on that entire die and you're probably fighting a losing battle attempting to get useful information out of it.

Well, either my system is reading a sensor under the socket instead, or the Linux sensors package is applying a calibration curve. While I obviously can't independently verify absolute accuracy, the numbers appear "reasonable" (30s at idle, 50s under full load), and if I reboot and go straight into the BIOS, the BIOS reading is within a few degrees of the last reading in the OS.

Given that power draw at the wall and reported temperature both remain absolutely steady when I schedule/deschedule cores under light system load, I'd say the CPU power sensor appears to be the "odd man out" here.

Yeah, it could be the temp sensor, but then some other mechanism would also be needed to explain why power draw at the wall doesn't change.

Sun Sep 25, 2016 7:46 am

...and in a peripherally related issue (in the sense that it also relates to power management under KDE), some recent update to the system or NVIDIA driver appears to have broken the display sleep functionality. The screen no longer turns off after the timeout specified in the KDE system settings. Some poking around with Google has not yielded a fix. As a workaround, I've added a few lines to my script to explicitly manage that as well. :roll:

Sun Sep 25, 2016 5:39 pm

Confirmed (more or less) that I've been reading the CPU socket temperature sensor, not the on-chip one. The on-chip one indeed reads way low (below ambient) under light load. If I stress the system (raising the temperature), after a few minutes the on-chip sensor and the socket sensor converge somewhat.

TR Forums

AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Re: AMD CPU power management in Kubuntu 14.04

Who is online