Subject: Re: Proposed changes to cc_microset().
To: None <tech-kern@NetBSD.org>
From: Alan Barrett <email@example.com>
Date: 07/08/2004 22:35:20
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
> 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)