又想中斷處理程式執行得快，又想中斷處理程式完成的工作量多，這兩個目的顯然有所抵觸。鑑於兩個目的之間存在此消彼長的矛盾關係，所以我們一般把中斷處理切為兩個部分或兩半。

中斷處理程式是上半部。接受到一箇中斷，他就立即開始執行，但只做嚴格時限的工作。例如對接受的中斷進行應答或復位硬體，這些工作都是在所有中斷被禁止的情況下完成的。能夠被允許稍後完成的工作會推遲到下半部(bottom half)去。此後，在合適的時機，下半部會被開中斷執行。Linux提供了實現下半部的各種機制。

1、"下半部"的起源

最早的Linux只提供"bottom half"這種機制用於實現下半部。這個名字在那時毫無異議，因為但是它是將工作推後的唯一方法。這種機制也被稱為"BH".BH介面非常簡單。他提供一個靜態建立，由32個bottom halves組成的連結串列。上半部通過一個32位整數中的一位來標示出哪個bottom half可以執行。每個BH都在全域性範圍內進行同步。即使分屬於不同的處理器，也不允許任何兩個bottom half同事執行。這種機制使用方便卻不夠靈活，簡單卻有效能瓶頸。

2、任務佇列

不久，核心開發者們就引入了任務佇列（task queue）機制來實現工作的推後執行。並用它代替BH機制。核心為此定義了一組佇列都包含一個由等待呼叫的函式組成連結串列。根據其所處佇列的位置，這些函式會在某個時刻執行。驅動程式可以把它們自己的下半部註冊到合適的佇列上去。這種機制表現得還不錯，但仍不夠靈活，沒法代替整個BH介面。對於一些效能要求較高的子系統，像網路部分，它也不能勝任。

3、軟中斷和tasklet

在2.3這個開發板中，核心開發者引入了軟中斷(softirqs)和tasklet。如果無需考慮過去開發的驅動程式相容的話，軟中斷和tasklet可以完全代替BH介面。軟中斷是一組靜態定義的下半部介面，有32個，可以在所有處理器上同時執行--即使兩個型別相同也可以。tasklet這一名稱取得很槽糕，讓人費解，他們是一種基於軟中斷實現的靈活性強，動態建立的下半部實現機制。