Page 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: CPUFreq Ondemand Could Be Faster, Use Less Power With Linux 3.17

  1. #1
    Join Date
    Jan 2007
    Posts
    14,810

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

    http://www.phoronix.com/vr.php?view=MTc0NzA

  2. #2
    Join Date
    Jan 2010
    Location
    Somewhere in Kansas.
    Posts
    263

    Default

    Thats very nice. Good Work!

  3. #3
    Join Date
    Feb 2008
    Location
    Santiago, Chile
    Posts
    242

    Default

    Is there a workaround we can use right now to replicate this?

  4. #4
    Join Date
    Feb 2013
    Posts
    59

    Arrow fjiowewefiojwefjiowefiojowefjiowiefjowefijefjfjiew jfowiejwoeijwefoijwefoijwefoijwefji

    Quote Originally Posted by Alejandro Nova View Post
    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??..
    I think a workaround until then would be go buy a faster processor..

  5. #5
    Join Date
    Sep 2010
    Posts
    683

    Default

    Quote Originally Posted by Baconmon View Post
    You can't wait until kernel 3.17 to have a 6% increase in speed??..
    I think a workaround until then would be go buy a faster processor..
    Go performance governor and tweak triggers.

    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)

  6. #6
    Join Date
    Jul 2009
    Posts
    258

    Default

    Quote Originally Posted by przemoli View Post
    Go performance governor and tweak triggers.

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

  7. #7
    Join Date
    Jun 2013
    Posts
    51

    Default

    Quote Originally Posted by jakubo View Post
    Maybe someone can help me understand. Why not use highest frequency when needed and when the job is finished fall back to lowest frequencies?
    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).

    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.

  8. #8
    Join Date
    Jul 2009
    Posts
    258

    Default

    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)

  9. #9
    Join Date
    Nov 2010
    Posts
    27

    Question

    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?

  10. #10
    Join Date
    Jun 2013
    Posts
    51

    Default

    Quote Originally Posted by jakubo View Post
    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)
    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.
    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.

    Quote Originally Posted by saski View Post
    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 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •