| Summary: | speedfreq-dynamic is not responsive to load | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | James Northrup <glamdring-inc> |
| Component: | [OLD] Unspecified | Assignee: | Mobile Herd (OBSOLETE) <mobile+disabled> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | minor | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
sys-power/speedfreq is deprecated in favor of sys-power/cpufreqd due to unresolved bugs and lack of upstream activity. If you would like to see this fixed, please contact upstream. |
Speedfreq "dynamic" setting is cool (literally), it saves me from burning all my cpu's wattage while my firewall/router/printserver idles at 300mhz (on a 2400 p4), and it dials in the mhz required for a moderate program to run at .8 idle which leaves room for responsiveness to new load. Every time I emerge it I hack this small tidbit in to solve the following author-documented idiosyncracy: "but some applications may experience erratic performance because of the latency in speeding up the CPU." When I ran vanilla speedfreq I would sometimes rifle through tons of diagnostics to locate the lag, before checking speedfreq. slow decay is fine but slow response is not as useful. Reproducible: Always Steps to Reproduce: 1. 2. 3. Expected Results: This one-line patch makes speedfreq perfect imho. it spikes the cpu frequency which will adjust itself down stepwise as usual. diff -u speedfreq-0.7.2/speedfreqd.c speedfreq-0.7.2b/speedfreqd.c --- speedfreq-0.7.2/speedfreqd.c 2003-10-17 21:56:53.000000000 -0700 +++ speedfreq-0.7.2b/speedfreqd.c 2005-02-22 18:31:08.173420744 -0800 @@ -464,7 +464,7 @@ } if (ratio < FREQ_UP) - target += FREQ_STEP; + target += FREQ_STEP*8; else if (ratio > FREQ_DOWN) target -= FREQ_STEP;