之所以设立软中断，是因为通过抽出一部分费时的操作，让硬中断可以很快结束，从而能够快速地响应更多的硬中断。
但是，内核里面又说，硬中断和软中断都是处于中断上下文，是不能够进程切换的！
硬中断不能切换我可以理解，可能就是因为需要快速结束，不允许切换进程，造成延迟。
1、但软中断，我就疑惑了，既然软中断就是为了处理费时操作的，结果还不允许进程切换，那不得一直占着CPU啊！
这不就是造成响应时间过长吗？
或者说，我理解的那种非常之费时的操作其实是放到工作队列当中实现了！
而真正放到软中断中实现的操作只是相对硬中断费时一点儿，当时绝不会长时间占用CPU！
2、还有一个问题，硬件中断和软件中断都是可以用户自定义的，
如果就遇到定义了一个while(true)之类的函数，不就死掉一个CPU了吗？
谢谢各位大神！
6 个解决方案
#1
因为中断中是没有「进程」的概念的，所以就更没有「进程切换」的概念了。
#2
在中断下半部，中断可以打开了
#3
中断中所有的费时操作都会放到工作队列中，由内核选出一个合适的时机去执行。中断的即时处理不能太长，这是编驱动时的原则。
#4
1 .软中断是linux系统原“底半处理”的升级，在原有的基础上发展的新的处理方式，以适应多cpu 、多线程的软中断处理。也就是说软中断跟硬中断一样，都有下半部分处理。
2. 一般while(true)这样的循环内部，要么有阻塞机制，要么有调度机制，绝不可能一直死循环下去。
2. 一般while(true)这样的循环内部，要么有阻塞机制，要么有调度机制，绝不可能一直死循环下去。
#5
擦，while是可被调度器切出去的，可调度的。。。
#6
1.是否可调度跟while这种逻辑控制代码无关。进程调度也是通过软中断来实现的。如果中断被禁用了，进程就无法调度了。
2.硬件中断处理程序里，一般都是禁用所有中断的（也就是说不允许中断嵌套，我说的是一般）。如果硬中断处理函数太费时，别的中断就无法响应了，并且进程无法调度，现象就是机器很卡。
3.软中断中，一般是可以响应硬件中断的，但无法进程调度。
至于楼主说的有人在中断中使用while(1)，这是不可能的。你会让自家的产品死掉吗？如果你是个打工的，且不说你的代码能不能通过申核，即使通过了，别人找出是你的问题了，老板还不直接把你开了
2.硬件中断处理程序里，一般都是禁用所有中断的（也就是说不允许中断嵌套，我说的是一般）。如果硬中断处理函数太费时，别的中断就无法响应了，并且进程无法调度，现象就是机器很卡。
3.软中断中，一般是可以响应硬件中断的，但无法进程调度。
至于楼主说的有人在中断中使用while(1)，这是不可能的。你会让自家的产品死掉吗？如果你是个打工的，且不说你的代码能不能通过申核，即使通过了，别人找出是你的问题了，老板还不直接把你开了
#1
因为中断中是没有「进程」的概念的，所以就更没有「进程切换」的概念了。
#2
在中断下半部，中断可以打开了
#3
中断中所有的费时操作都会放到工作队列中，由内核选出一个合适的时机去执行。中断的即时处理不能太长，这是编驱动时的原则。
#4
1 .软中断是linux系统原“底半处理”的升级，在原有的基础上发展的新的处理方式，以适应多cpu 、多线程的软中断处理。也就是说软中断跟硬中断一样，都有下半部分处理。
2. 一般while(true)这样的循环内部，要么有阻塞机制，要么有调度机制，绝不可能一直死循环下去。
2. 一般while(true)这样的循环内部，要么有阻塞机制，要么有调度机制，绝不可能一直死循环下去。
#5
擦，while是可被调度器切出去的，可调度的。。。
#6
1.是否可调度跟while这种逻辑控制代码无关。进程调度也是通过软中断来实现的。如果中断被禁用了，进程就无法调度了。
2.硬件中断处理程序里，一般都是禁用所有中断的（也就是说不允许中断嵌套，我说的是一般）。如果硬中断处理函数太费时，别的中断就无法响应了，并且进程无法调度，现象就是机器很卡。
3.软中断中，一般是可以响应硬件中断的，但无法进程调度。
至于楼主说的有人在中断中使用while(1)，这是不可能的。你会让自家的产品死掉吗？如果你是个打工的，且不说你的代码能不能通过申核，即使通过了，别人找出是你的问题了，老板还不直接把你开了
2.硬件中断处理程序里，一般都是禁用所有中断的（也就是说不允许中断嵌套，我说的是一般）。如果硬中断处理函数太费时，别的中断就无法响应了，并且进程无法调度，现象就是机器很卡。
3.软中断中，一般是可以响应硬件中断的，但无法进程调度。
至于楼主说的有人在中断中使用while(1)，这是不可能的。你会让自家的产品死掉吗？如果你是个打工的，且不说你的代码能不能通过申核，即使通过了，别人找出是你的问题了，老板还不直接把你开了