clock_getres and Kernel 2.6

生来就可爱ヽ(ⅴ<●) 提交于 2019-12-06 01:49:46

According to "include/linux/hrtimer.h" file from kernel sources, clock_getres() will always return 1ns (one nanosecond) for high-resolution timers (if there are such timers in the system). This value is hardcoded and it means: "Timer's value will be rounded to it"

http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/include/linux/hrtimer.h

269 /*
270  * The resolution of the clocks. The resolution value is returned in
271  * the clock_getres() system call to give application programmers an
272  * idea of the (in)accuracy of timers. Timer values are rounded up to
273  * this resolution values.
274  */
275 # define HIGH_RES_NSEC          1
276 # define KTIME_HIGH_RES         (ktime_t) { .tv64 = HIGH_RES_NSEC }
277 # define MONOTONIC_RES_NSEC     HIGH_RES_NSEC
278 # define KTIME_MONOTONIC_RES    KTIME_HIGH_RES

For low-resolution timers (and for MONOTONIC and REALTIME clocks if there is no hrtimer hardware), linux will return 1/HZ (typical HZ is from 100 to 1000; so value will be from 1 to 10 ms):

http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/include/linux/ktime.h#L321

321 #define LOW_RES_NSEC            TICK_NSEC
322 #define KTIME_LOW_RES           (ktime_t){ .tv64 = LOW_RES_NSEC }

Values from low-resolution timers may be rounded to such low precision (effectively they are like jiffles, the linux kernel "ticks").

PS: This post http://forum.kernelnewbies.org/read.php?6,377,423 as I can understand, compares 2.4 linux without hrtimers enabled (implemented) with 2.6 kernel with hrtimers available. So all values are correct.

Try to get it from procfs.

cat /proc/timer_list

Why do you think it is incorrect?

For example, on modern x86 CPUs the kernel uses the TSC to provide high resolution clocks - any CPU running at higher than 1Ghz has a TSC that ticks over faster than a tick per nanosecond, so nanosecond resolution is quite common.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!