non-invariant tsc and cputicker
Andriy Gapon
avg at freebsd.org
Sat Dec 4 11:12:14 UTC 2010
on 04/12/2010 02:38 Jung-uk Kim said the following:
> If my understanding is correct, your patch uses the dummy timecounter
> until a real timecounter is chosen.
Perhaps this is one way to look at it.
But I look at it differently - the patch makes cpu_ticks refer to tc_cpu_ticks.
That is, it make _the_ timecounter be used for cpu ticks.
Exact timecounter backend is not important to me.
> When a real timecounter is set,
> tc_cpu_ticks() changes the frequency naturally. How are you going to
> solve this problem?
Do we really care about cpu ticks accounting that early in the boot?
> What should we do when a user set a new
> timecounter hardware via "sysctl kern.timecounter.hardware"?
User can expect some instability (*if any*) when he does such a significant
system reconfiguration.
I put "if any", because I think that tc_cpu_ticks() should handle this.
The same way as you don't see time returned by e.g. nanotime() going crazy at
that moment.
> I don't
> think it is any better than current code. Am I missing
> something? :-(
I think that it is much better.
Handling of P-state changes for non-invariant TSC is just incorrect.
kern.timecounter.hardware is not going to be changed as frequently as P-states,
if ever.
--
Andriy Gapon
More information about the freebsd-current
mailing list