Messages in this thread | | | Date | Wed, 13 May 2009 00:42:50 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [PATCH] tsc_khz= boot option to avoid TSC calibration variance |
| |
On Tue, 12 May 2009, john stultz wrote: > > stored or accumulated before. For the TSC calibaration one could build the average > > of previous calibration values (if the value jumps between different numbers). > > That would require a sysctl (or equivalent) interface however. > > I still feel that a sysctrl or /sys/ interface for this sort of thing is > overkill. It creates yet another interface we have to manage, and really > doesn't improve the situation more then the boot option would. > Additionally it would require quite a bit of work at the clocksource > level to allow for re-calibration (currently we avoid this by > disqualifying the TSC if it changes freq). > > That said, I've gotten very few positive comments from my patch, so I'm > going to give it one more spin (to address Serge's point) and if folks > are still feeling blah about it I'll stop pushing it.
I'm fine with the command line option, but I refuse to add some sys/ thingy which makes us add extra calibration stuff.
Honestly all this is just the futile attempt to fix the flaws of NTP via (super)user interaction.
Darn, it can not be that hard to adjust the math to do what you think it should do. I'm not an expert on that NTP stuff, but blindly stuffing the last known value into the kernel and expect that the calibration value did not change is nonsense.
You know the calibration value which created the last known parameters and you want an extra interface to inject this last known calibration value into the kernel instead of doing the math of adjusting the NTP parameters according to the change of calibration values ?
Thanks,
tglx
| |