工作队列与软中断的区别

retuor

书上说工作队列由内核线程执行，可以睡眠，进程切换。软中断不可以。

问题：软中断也使用内核线程 ksoftirqd 来分担工作。既然都是内核线程，为何软中断就不能进程切换呢？

LKD 中有一段

当大量软中断出现的时候，内核会唤醒一组内核线程来处理这些负载。这些线程在最低的优先级上运行，这能避免它们跟其他重要任务抢夺资源。但他们最终肯定会被执行，所以，这个折中方案能够保证在软中断负担很重的时候用户程序不会因为得不到处理时间而处于饥饿状态。

这段话好像暗示进程被切换了？

retuor

难道是说那个 softirq 的 action 一旦被执行就不会被换出，在 action 内不可以睡眠？ 而 action 和 action 之间是可以睡眠，切换的？

networkdev

workqueue可以睡眠，但是软中断不可以

jinxinxin163

工作队列应该是由内核线程来负责工作队列中的函数(进程)的调度

jinxinxin163

当我们在工作队列中指定一个函数的时候，其实这个函数会以一个进程的形式存在，而工作队列的内核线程负责调度这些函数，也就是进程。所以工作队列可以进行进程切换。

而软中断，其实它在中断上下文，是在内核空间的东西，同样的，每个cpu都有一个内核线程来处理软中断（也可以说是调度软中断），但软中断已经在内核空间了，你还怎么进行进程切换呢？

tonyen

内核一部分软中断不是在线程里边执行的，只有在中断环境处理不完的软中断（比如循环10次），才会唤醒ksoftirqd 线程继续执行。

mapclm

这个问题要从软中断在linux系统的角色定位上考虑，简单来说，没有做中断线称化类似的前期工作，考虑中断上下文及处理软中断事件处理效率，就不切换了

kgn28

回复 1# retuor
关于他们的区别，ULK3是这么说的：

“The main difference is that deferrable functions run in interrupt context while functions in work queues run in process context. Running in process context is the only way to execute functions that can block (for instance, functions that need to access some block of data on disk) because, as already observed in the section "Nested Execution of Exception and Interrupt Handlers" earlier in this chapter, no process switch can take place in interrupt context. ”

工作队列执行时可以发生进程切换，而中断函数执行时不能发生进程切换（因为抢占计数器非零）。
另外关于ksoftirqd线程做的事情：

1. from:2.6.34(lxr.linux.no)
   
2. 695static int run_ksoftirqd(void * __bind_cpu)
   
3. 696{
   
4. 697        set_current_state(TASK_INTERRUPTIBLE);
   
5. 698
   
6. 699        while (!kthread_should_stop()) {
   
7. 700                preempt_disable();
   
8. 701                if (!local_softirq_pending()) {
   
9. 702                        preempt_enable_no_resched();
   
10. 703                        schedule();
    
11. 704                        preempt_disable();
    
12. 705                }
    
13. 706
    
14. 707                __set_current_state(TASK_RUNNING);
    
15. 708
    
16. 709                while (local_softirq_pending()) {
    
17. 710                        /* Preempt disable stops cpu going offline.
    
18. 711                           If already offline, we'll be on wrong CPU:
    
19. 712                           don't process */
    
20. 713                        if (cpu_is_offline((long)__bind_cpu))
    
21. 714                                goto wait_to_die;
    
22. 715                        do_softirq();
    
23. 716                        preempt_enable_no_resched();
    
24. 717                        cond_resched();
    
25. 718                        preempt_disable();
    
26. 719                        rcu_sched_qs((long)__bind_cpu);
    
27. 720                }
    
28. 721                preempt_enable();
    
29. 722                set_current_state(TASK_INTERRUPTIBLE);
    
30. 723        }
    
31. 724        __set_current_state(TASK_RUNNING);
    
32. 725        return 0;
    
33. 726
    
34. 727wait_to_die:
    
35. 728        preempt_enable();
    
36. 729        /* Wait for kthread_stop */
    
37. 730        set_current_state(TASK_INTERRUPTIBLE);
    
38. 731        while (!kthread_should_stop()) {
    
39. 732                schedule();
    
40. 733                set_current_state(TASK_INTERRUPTIBLE);
    
41. 734        }
    
42. 735        __set_current_state(TASK_RUNNING);
    
43. 736        return 0;
    
44. 737}

复制代码

明显可以看到在do_softirq后，是做了reschedule（717cond_resched();）的，而ksoftirqd的优先级比较低，所以很有可能被其他进程所替代，但是在执行do_softirq的时候是处于非抢占的中断上下文（premmt_count计数器非零）的。这样设计ULK3里面关于为什么是这样 说：

The first strategy consists of ignoring new softirqs that occur while do_softirq( ) is running. In other words, the do_softirq( ) function could determine what softirqs are pending when the function is started and then execute their functions. Next, it would terminate without rechecking the pending softirqs. This solution is not good enough. Suppose that a softirq function is reactivated during the execution of do_softirq( ). In the worst case, the softirq is not executed again until the next timer interrupt, even if the machine is idle. As a result, softirq latency time is unacceptable for networking developers.

The second strategy consists of continuously rechecking for pending softirqs. The do_softirq( ) function could keep checking the pending softirqs and would terminate only when none of them is pending. While this solution might satisfy networking developers, it can certainly upset normal users of the system: if a high-frequency flow of packets is received by a network card or a softirq function keeps activating itself, the do_softirq( ) function never returns, and the User Mode programs are virtually stopped.

无论是软中断还是硬中断，因为允许他们嵌套执行（nested），就不可能在执行中断函数的时候切走（switch_to）他们，因为这样就无法保证对中断的及时响应了。而软中断的设计目的应该是为了提高硬中断的吞吐率吧？

retuor

谢谢楼上几位，尤其是 kgn28。现在明白多了。

new_learner

问题：软中断也使用内核线程 ksoftirqd 来分担工作。既然都是内核线程，为何软中断就不能进程切换呢？
retuor 发表于 2010-06-27 13:55

softirq处理函数不能有引起进程切换的动作。虽然softirq处理函数在系统负载较大的情况下，会以ksoftirqd线程的形式来运行，但这是由kernel本身来控制的。你永远也无法知道自己编写的softirq处理函数是运行在中断上下文中，还是运行在线程中。

但work queue的设计就是让你的处理函数能够调用可能引起进程切换动作的函数，你根本就不需要考虑中断上下文这个概念。