我目前正在为块设备创建Linux驱动程序。这已经持续了一段时间，我最近刚刚将驱动程序设计从生物模式更改为请求模式（我曾经处理struct bio但现在我正在运行struct request）并且它使功能更简单，但是这一变化也提出了一些我要求建议的新问题。我还使用kthread进行背景维护，并定期刷新驱动程序设备循环缓冲区中的条目。
我在处理或完全理解时遇到困难的问题之一是在输入改变分区或文件系统类型的命令后，sbin / blkid进程的缓慢和存在。根据我目前的设计，每当我运行fdisk或mkfs或任何修改分区/ FS类型的命令时，在通过ps -ef terminal命令检查运行进程时，blkid进程将在之后运行，并且在完成之前大约需要一两分钟并更新磁盘工具（用户看到）中的驱动器信息。这当然等待太久了，我必须等到输入另一个修改分区/ FS类型的命令，否则驱动器信息搞砸了，分区表丢失等等。
我发现当我回到我之前的生物模式驱动程序（没有kthread）时，这个blkid任务也会在上述相同命令之后运行，但很快就完成了！我刚刚意识到blkid因为它现在很慢，而不是因为它很容易完成。因此我决定使用我的驱动程序代码，删除内容以查看哪个代码段导致缓慢的blkid，并最终发现kthread的存在与blkid的缓慢相关。
我的kthread BTW的主体如下：
while (kthread_should_stop()) {
set_current_state(TASK_INTERRUPTIBLE);
spin_lock_irq(&lock);
< driver code here... >
spin_unlock_irq(&lock);
schedule_timeout(msecs_to_jiffies(250));
}
这是我对kthread所做的事情：
- 慢慢删除代码，直到spin_lock / unlock调用之间没有任何内容。 sbin / blkid仍然很慢
- 删除kthread并将其替换为定期到期的计时器，重置自身，并在每次到期时调用一个函数，我移动了kthread驱动程序代码的内容。 sbin / blkid仍然很慢
- 将schedule_timeout时间值从250ms更改为1s - blkid变得更慢＆gt; 3mins。如果我把它减少到50ms，那就像250ms超时那样慢。
我真的很困惑 - 我的驱动程序kthread和blkid是如何以这种方式相互作用的，它会减慢blkid的速度？