Question

今天我发现了一个非常奇怪的问题。我运行Redhat Enterprise Linux 6，CPU是Intel E31275（4核，8个线程）。我发现一个内核线程（我称之为my_thread）无法正常工作。使用“ps”命令，我发现my_thread的状态始终在运行：

ps ax
5545 ?        R      3:14 [my_thread]
15774 ttyS0    Ss     0:00 -bash
...

但它的运行时间总是3:14。既然它已经运行，为什么总时间没有增加？从proc文件/ proc / 5545 / sched中，我发现此线程的所有统计信息包括wakeups count（se.nr_wakeups）也始终相同。

从/ proc / 5545 / stack，我发现这个线程调用了这个函数并且永远不会返回：

interruptible_sleep_on_timeout(&q, 3*HZ);

理论上，如果没有其他线程唤醒线程，此函数将每3秒返回一次。每次函数返回后，/ proc / 5545 / sched中的se.nr_wakeups都会增加1.但是在我发现线程出现问题之后，这种情况从未发生过。

有人有想法吗？是否有可能中断_sleep_on_timeout（）永远不会返回？

更新：我发现如果我为此线程设置CPU亲和性，则不会发生此问题。如果我将它固定到专用核心，那么一切都很好。 SMP调度有问题吗？

再次更新：我在BIOS中推翻了超线程后，直到现在我还没有看到这样的问题。

Answer 1

首先，R表示线程未处于运行状态但可运行。也就是说，它并不意味着它运行，这意味着它处于允许调度程序选择它运行的状态。两者之间存在很大差异。

在类似的意义上，interruptible_sleep_on_timeout（＆amp; q，3 * HZ）; 3个jiffies之后不会运行该线程，而是让它在3个jiffies之后运行 - 实际上你在“ps”中看到它可用于运行，所以可能确实发生了超时。

由于你没有说出有关内核线程的任何内容，我甚至不知道它是否在你自己的代码或标准内核代码中，所以我无法真正回答。

您描述的情况的一个可能原因是某些其他线程（用户或内核）具有比您的线程更高的优先级，因此调度程序从不选择它来运行。如果是这样，它可能不是以实时优先级运行的线程（SCHED_FIFO或SCHED_RR）。