我剛剛讀了第一次關於Linux內核中斷處理程序的下半部分，並試圖理解延遲工作的工作隊列的使用。睡在Linux工作隊列
據我所知，工作隊列優於softirps或tasklets的好處是工作在流程上下文中完成，因此可以進入休眠狀態。但是默認情況下，這項工作只是在其中一個事件/ X線程上按順序完成的？因此，如果說某些工作是在事件/ 0上開始的，然後在某個IO上等待很長時間，則不能在該處理器上處理更多工作隊列項目，這對於性能來說似乎非常糟糕。
那麼，如果工作可以長時間睡眠，那麼所有中斷處理程序開發人員都有責任不使用默認事件/ X線程？還是我誤解了一些東西？
但是默認情況下，這項工作是在一個事件/ X線程上按順序完成的？因此，如果說某些工作是在事件/ 0上開始的，然後在某個IO上等待很長時間，則不能在該處理器上處理更多工作隊列項目，這對於性能來說似乎非常糟糕。
這不是準確的; workqueue API允許單線程和多線程任務。對於前者，函數create_singlethread_workqueue（）被調用。
那麼，如果工作可以長時間睡眠，那麼所有中斷處理程序開發人員都不要使用默認事件/ X線程？還是我誤解了一些東西？
在軟中斷（即任務蕾）你不能在所有睡覺，所以基本上，工作隊列的好處是，你可以睡眠..真的 - 這是開發商的責任，不能引起其他kthreads餓死在單線程工況的情況。請注意，workqueue API不僅提供了入隊/出隊任務，還提供了排隊延遲工作，作品間同步，刷新工作隊列，取消延遲作品等功能。此API也是這是一個優於其他基於softirq的庫的優勢，即使對於非睡眠用法也是如此。