ULK:
The price to pay for allowing nested kernel control paths is that an interrupt handler
must never block, that is, no process switch can take place while an interrupt handler
is running. In fact, all the data needed to resume a nested kernel control path is
stored in the Kernel Mode stack, which is tightly bound to the current process.
Robert Love http://www.linuxjournal.com/article/6916 :
"...Let's discuss the fact that work queues run in process context. This is in contrast to the other bottom-half mechanisms, which all run in interrupt context. Code running in interrupt context is unable to sleep, or block, because interrupt context does not have a backing process with which to reschedule. Therefore, because interrupt handlers are not associated with a process, there is nothing for the scheduler to put to sleep and, more importantly, nothing for the scheduler to wake up..."
The question is 1) why no process switch can happen while an interrupt handler is running when allowing nested kernel control path? 2) Will process switch can happen while an interrupt handler is running if no nested kernel control path? In fact, no process switch should happen in either case. But why?
The interrupt handler may interrupt a running process,an exception handler, or an interrupt handler. But in the end, there is always a process context at the start being interrupted. Though the interrupted process has nothing to do with current interrupt handler, but current interrupt handler use the process's kernel stack anyway, so in a sense will it be possible to treat this process as the backing process of this interrupt handler, then a process switch can happen.
stackoverflow has 2 threads about this, thread 1 & thread 2. But not sure if it is enough.
In my opnion, it is possible for interrupt handler to do a process switch in technical perspective, though it needs lots of work.
However, the reason why Linux kernel doesn't allow process switch in interrupt handler I think is due to the design goal:
1) the current running process should not be interrupted long, since OS's main goal is do user's tasks by means of process. a process switch in interrupt handler will not only stop the interrupt handler, but also stop the interrupted process, imagine a process is stopped for things totally unrelated to itself.
2) interrupt handler should run as fast as possible to make I/O devices busy for efficiency. if interrupt handler stops by process switch, it can't process I/O device, image network interrupt handler or keyborad interrupt handler stop a while and resume execution long time later.
3) for nested interrupt handler, a process switch will stop all interrupt handlers in this nest, thus stop processing all related I/O devices.
others?
different opnion?