优先于SCHED_DEADLINE?

时间:2018-08-11 17:24:27

标签: debian real-time porting preempt-rt sched-deadline

在尝试调度高速线程时,我注意到有时有时会有很大的时间段(数毫秒)未调度该线程。我想知道在我正在使用的配置中,什么可以对调度程序执行此操作。

  • 带有RT(i686)的最新Debian拉伸(稳定)
  • 双核Intel(2237MHz)
  • PS2键盘和鼠标
  • 保留1个CPU(通过grub)
  • 用于将我的测试过程放到核心1上的任务集
  • 禁用SMI,禁用速度步进等(典型的RT BIOS设置)
  • 未禁用USB端口,但未插入任何端口
  • IRQ余额已禁用

我确认只有CPU1上有工作程序,计时器等内容。其他所有内容都在CPU0上。

我的线程是SCHED_DEADLINE(唯一这样安排的线程),周期为300us。我使用schedules_yield()释放线程,直到预留时间很久(只是一个测试循环),所以我确定它不会过度运行。

我得到的是一个几乎完美的3333Hz输出(通过一个o形示波器),它一次又一次被阻塞15ms以上。我已经研究了中断(除了计时器之外,该CPU上没有递增),我禁用了NMI中断,依此类推,因此无法找到干扰的过程。我不相信我能完全理解哪些优先事项会导致调度程序跳过句号,所以我希望有人可能有一个主意?

我认为这可能是磁盘IO,但这似乎与差距不符(有时确实如此)。 VGA /控制台的使用似乎会使情况变得更糟,但是即使不使用VGA,也仍然会出现差距。

是的,在您提出问题之前...。这只是一个实验,以查看是否可以可靠地完成此操作。我的实际代码在QNX上运行,在相同的硬件上以这种速率稳定运行。我正在尝试查看是否可以使用PREEMPT_RT将其移植到Debian。

谢谢!

1 个答案:

答案 0 :(得分:0)

SCHED_DEADLINE任务比其他所有具有不同优先级的用户级任务(即SCHED_RRSCHED_FIFOSCHED_OTHER)具有更高的优先级。

请注意,从内核4.16开始,可以通过使用SCHED_FLAG_DL_OVERRUNSIGXCPU信号上的用户级处理程序来检查溢出(请参见here)。

如果您需要检查CPU在做什么,ftrace可能是最好的方法。