On Thu, 08 Jul 2004, Frederick Bruckman wrote:
> In that case, we could just set ci_tsc_freq from that, and setting
> ci_cc_denom to zero (for each CPU) could force use of ci_tsc_freq
> to be used as a fallback until a proper calculation can be made.
> (Currently, it doesn't exactly do that.)

I don't think that's enough.  You have to allow for the fact that some
of the cycles betweeen the previous and the next calls to cc_microset()
were at the old frequency, and some will be at the new frequency.
That's why I think you have to update ci_cc_time to the time of the
frequency change.

> There's no need to reproduce much of cc_microset() in the est driver.

I wasn't suggesting anything like that.  The cc_changespeed() in my
previous message was intended to be an MI function, to be called
from the est driver.

> >And perhaps also add a way to to save a different value of
> >ci_tsc_freq for each speed known by the MD code?
>
> I'm not following you.

I was thinking of a lookup table that would map from machine-dependent
speed values (such as machdep.est.frequency.target) to ci_tsc_freq
values.  When the speed changes, check whether the table already
contains an appropriate cached value, and use it if available; else try
to calculate an approximation, and trigger a background process to make
a more accurate measurement and add it to the table.  This is probably
not worth the effort.

--apb (Alan Barrett)