【微信群技术讨论】threaded irq和工作队列(work queue)如何选择？
本文是原「蜗窝讨论区」的历史存档（2017-08-08），来自版块「Linux kernel技术问答」，共 5 帖。讨论区已停止服务，此处仅供查阅。
问题：threaded irq和工作队列(work queue)都是在进程上下文中处理中断下半部。什么时候选工作队列，什么时候选threaded irq? 谢谢。
讨论的结果： 1、threaded irq handler所在的进程（内核线程）的调度类别是SCHED_FIFO，即属于实时进程。而workqueue所依赖的线程池创建的worker线程属于普通进程。因此，如果有实时需求，优先选择threaded irq 2、如果没有实时需求，选择workqueue这个机制。
此外，还顺便讨论了workqueue的排队问题。threaded irq处理中断也是需要排队，但是这些中断事件一般来自一个驱动。而workqueue可能有多个驱动共享的情况，这时候，多个驱动的work被挂入了一个workqueue，需要排队处理。一般而言，除非work被阻塞，否则workqueue对应的线程池也不会创建新的worker线程。
有一位同学追问了一个问题： 现在的work都是提交到workpool里处理，那使用自己创建的workqueue和系统的workqueue有什么区别呢？
回答： CMWQ的目标之一就是明确的划分了workqueue的前端接口和后端实现机制。也就是说，用户应该关注workqueue的前端的那些接口，自己创建workqueue、销毁workqueue、queue一个work等，而具体后端采用什么机制（例如是否两个workqueue共用同一个worker thread pool）应该是用户不可见的。因此，为何要使用自己创建的workqueue而不使用系统的workqueue呢？这和workqueue属性相关，也就是说你要创建怎样的workqueue（bound or unbound，normal or high priority等），如果你的workqueue没有什么特别的属性，那么使用系统缺省的那些就OK了，但是如果系统中缺省创建的workqueue所具备的属性不符合你的需求，那么你就需要自己创建workqueue。但是，无论如何，底层是什么的线程池来处理其实用户是不需要关系的，系统可以做好一切的。
那到底要自己创建的workqueue还是使用系统的workqueue呢？一言以蔽之，如果没有需要，还是使用系统的workqueue吧。