如何在Linux内核空间中睡眠?

问题描述

我有一个内核线程，该线程在具有FIFO和最高优先级的特定CPU上分配.该线程会不时休眠，但是时间间隔必须尽可能精确.因此，考虑到这一点，在内核空间中最准确的睡眠方式是什么?

I have a kernel thread which is assigned on a specific CPU with FIFO and highest priority. This thread sleeps from time to time but the time interval must be as precise as possible. So with this in mind what would be the most precise way to sleep in the kernel space?

推荐答案

以下是文档/计时器/timers-howto.txt :

• 由busy-wait循环支持:
  udelay(unsigned long usecs)
  
• 由hrtimers支持:
  usleep_range(unsigned long min, unsigned long max)
  
• 由jiffies/legacy_timers提供支持
  msleep(unsigned long msecs)
msleep_interruptible(unsigned long msecs)
  

• Backed by busy-wait loop:
  udelay(unsigned long usecs)
  
• Backed by hrtimers:
  usleep_range(unsigned long min, unsigned long max)
  
• Backed by jiffies / legacy_timers
  msleep(unsigned long msecs)
msleep_interruptible(unsigned long msecs)
  

与*delay系列不同，其潜在机制 这些呼叫的驱动方式各不相同，因此有 您应该注意的怪癖.

Unlike the *delay family, the underlying mechanism driving each of these calls varies, thus there are quirks you should be aware of.

• 使用udelay
  
  • 为什么不usleep?
    在较慢的系统上，(嵌入式，或者可能是速度步进 PC！)设置hrtimers的开销 因为usleep 可能不值得.这样的评价 显然将取决于您的具体情况，但是 这是需要注意的事情.
  • Use udelay
    
    • Why not usleep?
      On slower systems, (embedded, OR perhaps a speed-stepped PC!) the overhead of setting up the hrtimers for usleep may not be worth it. Such an evaluation will obviously depend on your specific situation, but it is something to be aware of.
    • 使用usleep_range
      
      • 为什么msleep持续(1ms-20ms)?
        最初在这里解释:
        http://lkml.org/lkml/2007/8/3/250
        msleep(1〜20)可能无法满足呼叫者的意图，并且 通常会睡得更长一些(任何睡眠时间约20毫秒， 值在1〜20ms范围内).在许多情况下 不是期望的行为.
        
      • 为什么没有usleep/什么是好的范围?
        由于usleep_range是基于hrtimers构建的，因此 唤醒将非常精确(ish)，因此简单 usleep函数可能会引入大量 意外中断.
        
        随着范围的引入，调度程序是 可以自由地将您的唤醒与其他任何唤醒 可能是由于其他原因而发生的，或在 最坏的情况是为您的上限触发中断.
        
        您提供的范围越大，机会就越大 您不会触发中断；这应该 与可接受的上限保持平衡 特定代码路径的延迟/性能.精确的 这里的公差是非常具体的情况，因此 留给呼叫者确定合理的范围.
      • Use usleep_range
        
        • Why not msleep for (1ms - 20ms)?
          Explained originally here:
          http://lkml.org/lkml/2007/8/3/250
          msleep(1~20) may not do what the caller intends, and will often sleep longer (~20 ms actual sleep for any value given in the 1~20ms range). In many cases this is not the desired behavior.
          
        • Why is there no usleep / What is a good range?
          Since usleep_range is built on top of hrtimers, the wakeup will be very precise (ish), thus a simple usleep function would likely introduce a large number of undesired interrupts.
          
          With the introduction of a range, the scheduler is free to coalesce your wakeup with any other wakeup that may have happened for other reasons, or at the worst case, fire an interrupt for your upper bound.
          
          The larger a range you supply, the greater a chance that you will not trigger an interrupt; this should be balanced with what is an acceptable upper bound on delay / performance for your specific code path. Exact tolerances here are very situation specific, thus it is left to the caller to determine a reasonable range.
        • 使用msleep或可能的msleep_interruptible
          • 有什么区别?
            msleep将当前任务设置为TASK_UNINTERRUPTIBLE 而msleep_interruptible将当前任务设置为 TASK_INTERRUPTIBLE在安排睡眠之前.在 简而言之，区别在于睡眠是否可以结束 提前发出信号.通常，除非使用msleep，否则 您知道您需要可中断的变体.
          • Use msleep or possibly msleep_interruptible
            • What's the difference?
              msleep sets the current task to TASK_UNINTERRUPTIBLE whereas msleep_interruptible sets the current task to TASK_INTERRUPTIBLE before scheduling the sleep. In short, the difference is whether the sleep can be ended early by a signal. In general, just use msleep unless you know you have a need for the interruptible variant.

            这篇关于如何在Linux内核空间中睡眠?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！