Messages in this thread | | | Date | Sun, 29 Sep 2002 21:01:13 -0400 | From | Gerald Britton <> | Subject | Re: [PATCH] Re: [2.5.39] (3/5) CPUfreq i386 drivers |
| |
> > [rounding] > > There probably isn't a lot that can be done about these unfortunately, but > > they won't necessarily converge to a stable value so things may eventually > > start to fail. > Yes, that's a problem; but as cpufreq doesn't change speed dynamically yet > (and thus the number of transitions is somewhat limited) it shouldn't cause > too much trouble _yet_. But I'll try to think of a better solution _soon_.
One thought here might be.. for each variable which needs to be scaled, save off the boot value and boot frequency and always scale from that value so that we don't accumulate errors. Fairly simple implementation (i doubt there are very many things which will need scaling, so it doesn't bloat much). simply do something like this:
static unsigned int orig_freq; statid unsigned long orig_scalable; ... if (type == CPUFREQ_PRECHANGE) { if (!orig_freq) { orig_freq = freqs->old; orig_scalable = scalable; } if (scale_on_pre) scalable = cpufreq_scale(orig_scalable, orig_freq, freqs->new); } else if (type == CPUFREQ_POSTCHANGE) { BUG_ON(!orig_freq); if (scale_on_post) scalable = cpufreq_scale(orig_scalable, orig_freq, freqs->new); }
It seems to be working ok on my system adding saved boot values for loops_per_jiffy in cpufreq.c and cpu_khz, fast_gettimeoffset_quotient, and the per cpu loops_per_jiffy values in time.c.
-- Gerald
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |