linux内核驱动的 “msleep(1)” 真如你所愿延时1ms了吗？

在调试驱动的时候碰到这样一个问题，代码片段如下：用于统计"mleep(1)"实际消耗时长。

    struct timeval tpstart,tpend;
    unsigned long timeuses=0;
    do_gettimeofday(&tpstart);

    msleep(1);
    
    do_gettimeofday(&tpend);
    timeuses=(tpend.tv_sec-tpstart.tv_sec)*1000000+tpend.tv_usec-tpstart.tv_usec;
    printk("processor time %ld us\n",timeuses);

打印结果显示用时25ms左右，我的天！！！

探究msleep实现可参照博客“https://blog.csdn.net/tiantao2012/article/details/79373004”。

发现了“jiffies”一次，这个代表了系统启动以来系统中产生的总节拍数。节拍就是指系统中连续两次时钟中断的间隔时间，该值等于节拍率分之一，即1/Hz。因为系统再启动时已经设置了Hz，所以系统的节拍也可以确定。内核正是利用节拍来计算系统时钟和系统运行时间的。更多解释参照“https://blog.csdn.net/sdkdlwk/article/details/71158198”

查看当前kernel的Hz值：

make menuconfig

所以我们被msleep(1) "欺骗了"。实际上是以10ms为一个节拍，所以msleep(1)肯定大于10ms，但是为什么会大1倍这么多，个人感觉可能是精度问题或者是线程调度时间过长。如果有人看了这篇文章可以留言讨论“15ms去哪了”。

所以解决办法,就是把100Hz改为1000Hz再重新编译内核。

最后结果打印显示2.2ms。基本可用。