看了《深入理解linux內核》的中斷與異常，簡單總結了下，如果有錯誤，望指正！
一 什么是中斷和異常
異常又叫同步中斷，是當指令執行時由cpu控制單元產生的，之所以稱之為異常，是因為只有在一條指令結束之后才發出中斷（程序執行異常或者系統調用）。
中斷又叫異步中斷，是由其他硬件設備依照cpu時鍾信號隨機產生的。
二 高級可編程中斷控制器
APIC
每個CPU都有一個本地的APIC，通過IIC bus鏈接到一個I/O APIC，這個I/O APIC負責處理外部IRQS，分發IRQS給本地APIC。
三 中斷與異常處理程序嵌套執行
中斷處理程序允許被另一個中斷處理程序”中斷“，從而引起內核控制路徑嵌套執行。但是中斷處理程序是不允許發生阻塞，即任務切換的。
中斷可以搶占異常處理程序，但異常處理程序不會搶占中斷。因為中斷處理程序必定處於內核態，如果發生異常，那只能是BUG了，也就是說內核控制路徑中異常處理程序不會超過一個。
四 Linux中斷描述符
Intel把中斷描述符分三類：任務門、中斷門、陷阱門，而Linux則分成五類：
- 中斷門：Intel的中斷門，DPL = 0，描述中斷處理程序，通過set_intr_gate宏設置
- 系統門：Intel的陷阱門，DPL = 3，用於系統調用，通過set_system_gate宏設置
- 系統中斷門：Intel的中斷門，DPL = 3，用於向量3的異常處理，通過set_system_intr_gate宏設置
- 陷阱門：Intel陷阱門，DPL = 0，大部分的異常處理，通過set_trap_gate宏設置
- 任務門：Intel任務門，DPL = 0，對”Double fault“異常處理，通過set_task_gate宏設置
五 異常處理
當cpu產生異常時，會自動根據產生的異常編號在IDT中找對應的異常處理程序，異常處理程序保存大多數寄存器的值，調用異常處理的高級C函數處理該異常，然后通過調用ret_from_exception從異常處理程序退出。
六 中斷處理
I/O中斷處理程序執行的四個基本過程：
- 在內核態堆棧中保存IRQ的值和寄存器的內容
- 給正在為IRQ線服務的PIC發送一個應答，這將允許該PIC進一步發中斷
- 執行共享該IRQ的所有設備的中斷服務例程（ISR）
七 IRQ數據結構
IRQ數據結構
hw_irq_controller是對PIC進程控制的一些函數，包括應答PIC什么的。action指向的是一個irqaction鏈，每個irqaction描述一個設備的服務例程。irq_desc_t中的state字段保證了同一時刻只有一個設備會擁有該IRQ，正在處理該IRQ的CPU會禁用這條IRQ（本地），其它cpu還是可以接受該IRQ的請求，不過由於此時state的狀態為IRQ_INPROGRESS，所以新的IRQ請求會在其它的CPU上應答，但不會處理，也就是該新的IRQ處理會被延遲到處理同一個IRQ的前面一個CPU上執行。能這樣做是因為IRQ的數據結構是所有CPU所共享的。
八 多種類型的內核棧
如果編譯內核設置內核棧為8k，那么進程的內核棧被用於所有類型的內核控制路徑。如果內核棧為4k，則內核使用3種類型的內核棧：異常棧，用於處理異常，每個進程一個；硬中斷棧，用於處理中斷，每個cpu一個；軟中斷棧，用於處理延遲函數，每個cpu一個。
九 軟中斷
1 為什么要引進軟中斷機制，用前面的中斷機制不就可以了嗎（老版本的linux就沒有軟中斷機制）？
從前面的中斷處理中可以看出，一個中斷處理程序的幾個中斷服務例程（每個設備一個）是串行執行的，如果某個處理例程執行的時間比較長，而后面的例程又很緊急，那么會導致這個緊急的例程會延遲比較久的時間。所以如果能把一些服務例程中不是很緊急但又花費比較長的操作延遲到執行完該IRQ上所有中斷服務例程之后執行，那么一些緊急的，花費時間短（一般緊急的操作所需的時間都是比較短的）的例程就可以得到快速的響應。還有就是對於某個設備的中斷服務例程，如果它的服務例程服務時間過長，cpu在執行該服務例程時是會中斷本地cpu對該設備的中斷或者整個本地中斷，這樣會導致很多中斷會得不到快速的響應。所以為了處理這兩個問題，內核使用軟中斷來解決，軟中斷通常處理中斷中比較耗時的操作，並且執行期間允許本地中斷。
2 軟中斷使用的關鍵數據結構
softirq_vec數組，每個數組元素類型為softirq_action，該數組總共有32個元素，目前只用了前面六個。softirq_action數據結構包含兩個字段：指向軟中斷處理函數的action指針和指向軟中斷函數需要的通用數據結構的data指針，這是cpu共享的。
每個進程描述的thread_info字段中的preempt_count字段，該字段被編碼來表示三個不同的計數器和一個標志。0-7位表示是否允許搶占內核，8-15表示是否正在處理軟中斷，16-27表示硬件中斷控制路徑嵌套數，28為是PREEMPT_ACTIVE標志。每個進程有一個。
另一個是每個cpu都有的32位掩碼，存放在irq_cpustat_t數據結構中的__softirq_pending字段，32位，每一位表示softirq_vec數組中的對應的軟中斷函數是否已激活。irq_cpustat_t存放在irq_stat數組中，每個cpu對於數組中的一個irq_cpustat_t。每個cpu一個。
3 軟中斷可延遲函數的四個操作
- 初始化，定義一個新的可延遲函數，並加入到softirq_vec數組中，所有cpu共享該softirq_vec。
- 激活，標記一個可延遲函數為”掛起“，通過前面描述的__softirq_pending字段。
- 屏蔽，有選擇地屏蔽一個可延遲函數，即使它被激活。它是通過前面的preempt_count字段或者關閉本地中斷（延遲函數一般是通過中斷處理程序激活的，如果沒有中斷處理程序執行，自然也就不會有延遲函數的激活）來實現的。
- 執行，執行一個掛起的可延遲函數和同類型的其它掛起的可延遲函數。通過do_softirq實現。
激活和執行可延遲函數必須要在同一個cpu上，從前面激活和執行可以看出這一點。因為__softirq_pending是每個cpu一個，所有在特定cpu激活的延遲函數，只有在該cpu上的__softirq_pending標記被激活，而其它cpu是不知道該函數被激活的，也就不會去執行該函數了。
4 linux現有的六種軟中斷
處理高級優先級的tasklet軟中斷HI_SOFTIRQ，在softirq_vec數組的下標為0；和時鍾中斷關聯的tasklet軟中斷TIMER_SOFTIRQ，在softirq_vec數組的下標為1；把數據包傳送到網卡軟中斷NET_TX_SOFTIRQ，在softirq_vec數組的下標為2；從網卡接收數據包的軟中斷NET_RX_SOFTIRQ，在softirq_vec數組的下標為3；SCSI命令中斷處理的軟中斷SCSI_SOFTIRQ，在softirq_vec數組的下標為4；處理常規tasklet軟中斷TASKLET_SOFTIRQ，在softirq_vec數組的下標為5；它們的優先級是從高到低的。
5 檢查是否有軟中斷掛起（也叫激活）的時機
- 內核調用local_bh_enable激活本地軟中斷
- 當do_IRQ完成了I/O中斷的處理或調用irq_exit時
- smp_apic_timer_interrupt處理完本地定時中斷
- cpu處理CALL_FUNCTION_VECTOR中斷處理
- 當一個特殊的ksoftirq/n內核線程被喚醒。
ksoftirq/n內核線程是專門用來處理已經激活的軟中斷的，每個cpu有一個。
十 tasklet
tasklet是在軟中斷的基礎上實現的。正如前面說的linux現有的六種軟中斷，其中HI_SOFTIRQ和TASKLET_SOFTIRQ軟中斷就是tasklet。
對於每種tasklet（HI_SOFTIRQ和TASKLET_SOFTIRQ），每個cpu都有一個tasklet_head類型來描述這種tasklet。tasklet_head類型指向了一個由tasklet類型組成的鏈表，而每個tasklet類型描述了該tasklet要執行的函數和函數需要的數據以及tasklet的狀態（狀態表示同一個tasklet是否正在其它cpu上運行等）。
為什么在運行一個tasklet之前要檢查這個tasklet是否正在運行呢？當一個tasklet被調度了，並正在運行的時候，這個tasklet又在另一個cpu被調度了，這樣很可能出現這個tasklet同時在兩個cpu上運行，為了防止這種情況才需要每次運行一個tasklet之前檢查該tasklet是否正在運行。
只要一個tasklet的TASKLET_STATE_SCHED標記被清除了，它就可以被用於調度，即使可能這個tasklet還正在運行。這樣做是為了讓不相同的tasklet能夠同時地執行，這顯然比讓一個tasklet執行完之后再調度它效率高（通常tasklet執行時間比中斷處理程序都是長的）。
當do_softirq處理軟中斷時，如果相應的HI_SOFTIRQ和TASKLET_SOFTIRQ軟中斷被激活，就會調用對應的軟中斷函數tasklet_hi_action和tasklet_action。而這兩個函數處理的數據正是HI_SOFTIRQ和TASKLET_SOFTIRQ類型tasklet所對應的tasklet_head類型指向的tasklet鏈表。
為了能夠寫自己的tasklet函數並加入到對應tasklet類型的tasklet_head指向的鏈表中，需要調用tasklet_init來初始化新的tasklet和調用tasklet_schedule或tasklet_hi_schedule來把我們自定義的tasklet加入到對應的tasklet_head指向的鏈表中並激活該tasklet類型所對應的軟中斷。
所以說tasklet是在軟中斷的基礎上實現的，但不同的是軟中斷是靜態分配的（linux分配了6個軟中斷），而tasklet是可以動態加入和刪除tasklet的。
十一 工作隊列
每個工作隊列，在每個cpu上都有一個cpu_workqueue_struct結構來描述，即對於同一個工作隊列，每個cpu都有該隊列的一個拷貝。cpu_workqueue_struct中的worklist成員指向了由work_struct結構組成的鏈表，這個鏈表描述的是該工作隊列被掛起的函數，等待工作者線程去執行。
通過調用create_workqueue創建工作隊列。如果是smp，則每個cpu都會創建一個工作隊列和為該工作隊列工作的工作者線程。該工作者線程一直阻塞，直到有函數被加入到工作隊列中去，工作者線程執行了函數之后就把函數從工作隊列中刪除。
可以通過queue_work函數把一個函數加入到工作隊列中去。
由於僅僅為了一個函數就創建一個工作隊列開銷太大，所以內核預定義了一個叫events的工作隊列，為該隊列工作的工作者線程叫events/n，每個cpu一個。還有就是專門為塊設備使用的kblocked工作隊列。
十二 軟中斷與工作隊列的區別
從上面可以看出，軟中斷和工作隊列十分的相似，都是對服務例程中某些耗時的操延后處理。主要區別在於，軟中斷的可延遲函數是在中斷上下文中執行的，而工作者隊列的函數則是在進程上下文中執行的，也就是說軟中斷的延遲函數執行期間不允許內核被搶占，而工作隊列則是可以的。