Re: [PATCH] Re: [2.5.39] (3/5) CPUfreq i386 drivers

[Gerald Britton <gbritton@alum.mit.edu>]

> > [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