簡單來說，在內核中使用delay函數，如果調用schedule_timeout有可能被signal打斷，導致delay的時間小於預期，而mdelay可以確保等待的時間大於等於參數設置的時間，在一些hardware驅動當中使用的delay，安全起見，一般推薦使用mdelay或者usleep_range函數。
至於里面的原理，引用公司某大牛的解釋：
schedule_timeout會做兩件事
1. 設置timer
2. Schedule
他不會把當前的進程的狀態由TASK_RUNNING變為TASK_INTERRUPTIBLE和TASK_UNINTERRUPTIBLE或者TASK_KILLABLE
所以在__schedule()中，不會把這個task從runqueue中移出去。那么當系統進行調度的時候這個進程仍然會被調度進來。
所以推薦調用
Schedule_timeout_interruptible
Schedule_timeout_uninterruptible
Schedule_timeout_killable
這幾個函數都會在調用schedule_timeout之前調用set_current_state，來把進程的狀態設置為非TASK_RUNNING得狀態。
其中msleep就是調用schedule_timeout_uninterruptible。
Unterruptible就是不能被signal打斷，任何signal都不行，包括優先級最高的不可忽略的SIG_KILL。
這也就是為什么我們會ps的時候看見進程狀態是”D”。之所以這么做是由於一些系統的io不能接受打擾。唯一能喚醒io等待進程的就是別人wakeup他。
VPU的驅動就是這種情況，會在release的時候等待硬件不再busy，然后關clock。如果不用uninterruptible，而用interruptible，
那么用戶kill VPU的進程，盡管我們在release的時候用了schedule（schedule_timeout會調用schedule），但是schedule會立刻返回，因為其中有判斷：如果是非uninterruptible並且有signal pending，那么task的狀態會被設置為TASK_RUNNING，並且立刻返回，不會做context switch. 所以這兒必須要schedule_timeout_uninterruptible。
系統也提供了新的狀態TASK_KILLABLE。這個和TASK_UNINTERRUPTIBLE的區別就是這個進程能被SIG_KILL的signale喚醒。在文件系統中用的可能比較多。大家可能會碰到使用這種TASK_KILLABLE的情況。