CPUFreq Ondemand Could Be Faster, Use Less Power With Linux 3.17
Phoronix: CPUFreq Ondemand Could Be Faster, Use Less Power With Linux 3.17
Improvements to the CPUfreq ondemand governor could lead to faster performance in low to medium workloads with the Linux 3.17 kernel while also consuming less power overall...
Thats very nice. Good Work!
Is there a workaround we can use right now to replicate this?
You can't wait until kernel 3.17 to have a 6% increase in speed??..
Originally Posted by Alejandro Nova
I think a workaround until then would be go buy a faster processor..
Go performance governor and tweak triggers.
Originally Posted by Baconmon
It will also help with multi threaded games. Where ondemand seriously underperformed by setting too low frequencies, then moving threads between cores, then increasing frequencies, then moving threads, then...
Go performance governor (especial if You already use Intel P-State driver)
Maybe someone can help me understand. Why not use highest frequency when needed and when the job is finished fall back to lowest frequencies?
Originally Posted by przemoli
The ones in between would only be necessary if some synchronisation/io wait occurrs frequently.
Would it not make sense to calculate a per frequency workload? and when it reaches a certain point it shall jump to a higher/lower state? or is there too much hysteresis?
How is it done now? i didnt quite get it.
The issue with jumping between the max and min frequencies is that it assumes the job is cpu-bound and finishes quickly. Consider something like video playback, where you have a moderate but continuous load for a long period of time. There is no advantage to using a higher frequency, and it just consumes more power; the ideal frequency is the minimum which can meet the performance requirements (i.e. no dropped frames).
Originally Posted by jakubo
Scaling the frequency proportional to the load has the nice property that it introduces a feedback loop - if you scale the frequency high enough the cpu usage will drop below 100% (most loads are not entirely CPU bound), and you reach a steady state.
but if you just said
if currentCPUload > upper boundary (for instance 95%) --> go step up
if currentCPUload < lower boundary (for instance 60%) --> go step down
wouldnt it suffice?
or would it be jumping too much between states?
Higher frequencies are more efficient right? (less total memory refreshes per task and sharper signal edges)
Question: Why would one still use the CPUFreq govenors on a SNB+ Core i7 machine while Intel provides their P-State govenor that supposedly run much more efficient on their CPUs? What is the advantage?
The approach you suggest would be less responsive. i.e. it would take more iterations to reach the desired state. Hysteresis (jumping between states) would be a problem too, depending on how you tuned it.
Originally Posted by jakubo
I suspect the reason the algorithm is designed that way is that it makes it much easier to apply control theory to its design, since the definition does not rely on current state.
The CPUFreq governors offer more control. That said, according to this appears that even if CPUFreq specifies a certain frequency, the governor built into the CPU treats it as a suggestion only.
Originally Posted by saski