28/01/2014 02:16, Sangjin Han: > >> It would be nice if I can bypass set_tsc_freq_from_cpuinfo() in > >> set_tsc_freq(). > > > > I think it would not solve the problem because your clock is varying and > > the TSC calibration must be updated accordingly with different values by > > core.
[...] > Also, it seems that there is no guarantee that the TSC rate is > identical to the CPU max clock frequency. So you may submit a revert of the commit a46154b9c6bc (timer: get TSC frequency from /proc/cpuinfo) > I would like to suggest two possible options: > > 1. If we can assume that the TSC rate always equals to the max clock > frequency, then we can use > /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq instead of > /proc/cpuinfo (which reflects cpuinfo_cur_freq). > > 2. If we can't (AMD?), we can simply get rid of > set_tsc_freq_from_cpuinfo() and fall back to set_tsc_freq_from_clock() > or set_tsc_freq_ballback() instead. I always get reasonably good > accuracy with those two functions -- the only drawback is that it > takes 0.5 - 1 second for applications to boot up. Not sure if it is a > big deal or not, though. Maybe that you can choose between these two methods with a runtime option. > Besides the TSC frequency, the 4ms * 10 delay in > ixgbe_reset_pipeline_82599() seems too tight. On my system, it > succeeds only after 7 (or so) iterations with correct msec_delay(). > The per-iteration delay (4ms; in the kernel ixgbe driver, it is set to > be 4-8ms) and/or the number of iterations (10) should be increased, I > suppose. Feel free to submit a patch. -- Thomas
