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 _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
