Delayed profile change
Brought to you by:
mattia-san
Menu
▾
▴
#6 Delayed profile change
Would it make sense to add a variable to a profile
which would delay the change to another profile? Or
rule, I'm not sure where it would apply best. I would
like cpufreqd to stay in a certain profile just a
little bit longer, even if a slower profile has more
hits. I find that when my cpu starts working hard, most
likely it will work hard, pause, work hard again. but
if the speed profile keeps changing, there's that lag
before going back to full speed. Adding a delay would
smooth things out.
Ex:
[Profile]
name=full
maxfreq=3066590
minfreq=3066590
policy=performance
delay=5
[Profile]
name=coma
maxfreq=383323
minfreq=383323
policy=powersave
cpufreqd would stay at full speed for 5 seconds before
dropping back to coma. Or maybe it could mean for 5
sampling intervals. Then at the 6th interval (or
second), it can pick another profile.
Logged In: NO
edit: after thinking a little more, having the delay
variable in a rule makes more sense.
you can also differentiate between a delay in seconds or a
delay in sampling intervals by using
delay=5s
delay=5i
Logged In: NO
edit: after thinking a little more, having the delay
variable in a rule makes more sense.
you can also differentiate between a delay in seconds or a
delay in sampling intervals by using
delay=5s
delay=5i
Logged In: YES
user_id=584271
yes, I noticed this behaviour long ago...
You could try setting overlapping values for your rules,
thus you will have some kind of "limbo" where 2 rules get
the same score and only one of them will stay active during
this limbo.
let me know, otherwise I'll try to think something else.
Your idea could lead to problems as: if you system status is
varying a lot, summing delays between profiles could make a
rule to never apply even if it's the most appropriate...
Logged In: YES
user_id=1123952
have an account now, wish I could remove the extra post, not
sure how it got there.
I'm not yet sure how overlapping values would work.
I'm patching it myself to do the interval delay idea, just
for shits&giggles.
Logged In: YES
user_id=584271
good, let me know if you get the desired result, I'll
consider your patch for inclusion.
about overlapping values simply create the your rules like:
[Rule]
cpu_interval=30-100
...
[Rule]
cpu_interval=0-70
...
so in the 30-70 interval both rules can be valid choices.
You'll get some kind of delay between switches. Also
increasing the polling frequency can give the result of
delayed frequency switches.
Logged In: YES
user_id=1123952
I have it running now, seems ok. So far I think it's too
much of a dirty hack to be used by mainstream, needs refining.
I guess I'm looking for some sort of
aggressive-increase/passive-decrease logic.
I'm thinking about changing it again so that any faster rule
picked will be applied without hesistation, but a slower
rule will get delayed.
Of course, I'm sure there is some mathematically correct way
to compute what frequency to pick, based on load history,
etc. Even throw in Fourier transformation and state machines
or something.
heh, and no doubt so much computation would end up skewing
the load.
Logged In: YES
user_id=1123952
I have it running now, seems ok. So far I think it's too
much of a dirty hack to be used by mainstream, needs refining.
I guess I'm looking for some sort of
aggressive-increase/passive-decrease logic.
I'm thinking about changing it again so that any faster rule
picked will be applied without hesistation, but a slower
rule will get delayed.
Of course, I'm sure there is some mathematically correct way
to compute what frequency to pick, based on load history,
etc. Even throw in Fourier transformation and state machines
or something.
heh, and no doubt so much computation would end up skewing
the load.
Logged In: YES
user_id=1123952
I have it running now, seems ok. So far I think it's too
much of a dirty hack to be used by mainstream, needs refining.
I guess I'm looking for some sort of
aggressive-increase/passive-decrease logic.
I'm thinking about changing it again so that any faster rule
picked will be applied without hesistation, but a slower
rule will get delayed.
Of course, I'm sure there is some mathematically correct way
to compute what frequency to pick, based on load history,
etc. Even throw in Fourier transformation and state machines
or something.
heh, and no doubt so much computation would end up skewing
the load.
Logged In: YES
user_id=654238
Maybe instead of a delay in seconds or cycles, it would make
more sense to introduce an 'at least x hits' rule.
So each cycle the profile that gets the higher score gets a
counter increased, if this counter reaches the 'at least x
hits' number, it switches to that profile.
In the case of the scenario initially suggested: heavy load,
short pause, heavy load, ....
set the 'full' profile with 'at least x hits'=1
set the 'coma' profile with 'at least x hits'=3
This way it'd be less likely that we switch to the 'coma'
profile during heavy load.
Logged In: YES
user_id=32787
I've tried to implements this. Seems to work. A patch is
available from the patches page.