Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#5 taking idle time in account

closed
None
5
2005-08-25
2004-09-06
Jeremy VIES
No

I've think about an interesting feature (at least for
me :) ) :
cpufreqd could take idle time in account to choose a
valid rule.

I explain:

when I use my laptop normally, it runs at ~800mhz.
when I run big application, it runs faster.
I'd like when I run nothing after 5 minutes, it runs
slower... to save battery when I am running on battery,
or to cool the cpu a little bit more...

I've not written any code about it... but if you think
it is interesting, I will try to implement it...

Discussion

  • Mattia Dongili
    Mattia Dongili
    2004-09-09

    Logged In: YES
    user_id=584271

    Hi,

    isn't cpu usage monitoring suficient?

    (thanks :) and sorry... I'm a pretty busy recently)

     
  • Jeremy VIES
    Jeremy VIES
    2004-09-09

    Logged In: YES
    user_id=1117117

    Well, I think no...
    Because I like to have my computer running at a medium speed
    to have good response time. I mean I have ask my laptop to
    run at 800 to be enough reactive.
    Before I used it at only 500 mhz, and each time I wanted to
    run an application it took 2 seconds to start.
    Maybe I could try to have more level of cpu monitoring...
    and not only very few cpu, or a lot of cpu...

     
  • Mattia Dongili
    Mattia Dongili
    2004-09-17

    • assigned_to: nobody --> mattia-san
     
  • hannibal218bc
    hannibal218bc
    2005-02-16

    Logged In: YES
    user_id=613520

    Hi all,

    my machine is a Pentium 4 HT, which I throttle down with
    cpufreqd during inactive periods to save power (and noise
    and heat).

    Choosing the right frequency only based on CPU load proved
    to be insufficient, because 80% CPU used @375 MHz is not
    quite the same as 80% CPU @3 GHz, so I'd like either taking
    idle time (or total clock cycles available or something) or
    current speed into account when choosing rules.

    I tried creating rules with small overlapping boundaries so
    that the maximum number of used clock cycles at a lower
    frequency is just a little greater than the minimum number
    of used clock cycles at the next higher frequency, but it
    seems I either got something wrong (and can't figure it out)
    or my idea is fundamentally flawed.

    Perhaps a totally different concept would work too:
    <suggestion>What about some special kind of profile with
    following parameters:
    * minimum % CPU used to increase frequency
    * maximum % CPU used to decrease frequency
    * number of steps to take when scaling up/down (skip X
    available frequencies)
    </suggestion>

    As - at least here - load doesn't increase by much in a
    couple of seconds, I think this might be an interesting
    algorithm to try.

    What do you think?

    With best regards,
    -hannes

     
  • Mattia Dongili
    Mattia Dongili
    2005-02-16

    Logged In: YES
    user_id=584271

    Hi,
    what you're describing is currently implemented in other
    userspace daemons or in newer cpufreq kernel governors
    (kernel > 2.6.9-rc3 see the 'ondemand' governor).
    Actually cpufreqd is a profile based tool, so it exploits
    the fact that policies like that are implemented _in-kernel_
    This is the only place where such policies can be effective,
    polling cpu usage in userspace is a palliative and cannot be
    done without much unnecessary overhead. Also an in-kernel
    policy can answer promptly to cpu demand, a userspace policy
    don't.

    (If you whish to talk more on the subject I'd appreciate if
    you could use the mailing list, this web based interface is
    pretty annoying :))

     
  • hannibal218bc
    hannibal218bc
    2005-02-17

    Logged In: YES
    user_id=613520

    hi,

    thanks for your pointer to the ondemand governor -- this is
    it, and it works like a charm.

    sorry for annoying you with the reply here, but i felt it
    belongs to the feature request.

    liebe gre,
    -hannes

     
  • Mattia Dongili
    Mattia Dongili
    2005-08-25

    • status: open --> closed