linux中斷分配

㈠ 《linux設備驅動程序》（十六）-中斷處理

設備與處理器之間的工作通常來說是非同步，設備數據要傳遞給處理器通常來說有以下幾種方法：輪詢、等待和中斷。

讓CPU進行輪詢等待總是不能讓人滿意，所以通常都採用中斷的形式，讓設備來通知CPU讀取數據。

2.6內核的函數參數與現在的參數有所區別，這里都主要介紹概念，具體實現方法需要結合具體的內核版本。

request_irq函數申請中斷，返回0表示申請成功，其他返回值表示申請失敗，其具體參數解釋如下：

flags 掩碼可以使用以下幾個：

快速和慢速處理常式 ：現代內核中基本沒有這兩個概念了，使用SA_INTERRUPT位後，當中斷被執行時，當前處理器的其他中斷都將被禁止。通常不要使用SA_INTERRUPT標志位，除非自己明確知道會發生什麼。

共享中斷 ：使用共享中斷時，一方面要使用SA_SHIRQ位，另一個是request_irq中的dev_id必須是唯一的，不能為NULL。這個限制的原因是：內核為每個中斷維護了一個共享處理常式的列表，常式中的dev_id各不相同，就像設備簽名。如果dev_id相同，在卸載的時候引起混淆（卸載了另一個中斷），當中斷到達時會產生內核OOP消息。

共享中斷需要滿足以下一個條件才能申請成功：

當不需要使用該中斷時，需要使用free_irq釋放中斷。

通常我們會在模塊載入的時候申請安裝中斷處理常式，但書中建議：在設備第一次打開的時候安裝，在設備最後一次關閉的時候卸載。

如果要查看中斷觸發的次數，可以查看 /proc/interrupts 和 /proc/stat。

書中講述了如何自動檢測中斷號，在嵌入式開發中通常都是查看原理圖和datasheet來直接確定。

自動檢測的原理如下：驅動程序通知設備產生中斷，然後查看哪些中斷信號線被觸發了。Linux提供了以下方法來進行探測：

探測工作耗時較長，建議在模塊載入的時候做。

中斷處理函數和普通函數其實差不多，唯一的區別是其運行的中斷上下文中，在這個上下文中有以下注意事項：

中斷處理函數典型用法如下：

中斷處理函數的參數和返回值含義如下：

返回值主要有兩個：IRQ_NONE和IRQ_HANDLED。

對於中斷我們是可以進行開啟和關閉的，Linux中提供了以下函數操作單個中斷的開關：

該方法可以在所有處理器上禁止或啟用中斷。

需要注意的是：

如果要關閉當前處理器上所有的中斷，則可以調用以下方法：

local_irq_save 會將中斷狀態保持到flags中，然後禁用處理器上的中斷；如果明確知道中斷沒有在其他地方被禁用，則可以使用local_irq_disable，否則請使用local_irq_save。

locat_irq_restore 會根據上面獲取到flags來恢復中斷；local_irq_enable 會無條件打開所有中斷。

在中斷中需要做一些工作，如果工作內容太多，必然導致中斷處理所需的時間過長；而中斷處理又要求能夠盡快完成，這樣才不會影響正常的系統調度，這兩個之間就產生了矛盾。

現在很多操作系統將中斷分為兩個部分來處理上面的矛盾：頂半部和底半部。

頂半部就是我們用request_irq來注冊的中斷處理函數，這個函數要求能夠盡快結束，同時在其中調度底半部，讓底半部在之後來進行後續的耗時工作。

頂半部就不再說明了，就是上面的中斷處理函數，只是要求能夠盡快處理完成並返回，不要處理耗時工作。

底半部通常使用tasklet或者工作隊列來實現。

tasklet的特點和注意事項：

工作隊列的特點和注意事項：

㈡ Linux內核中斷之中斷調用流程

本文基於 RockPI 4A 單板Linux4.4內核介紹中斷調用流程。

ARMv8包括兩種運行狀態：AArch64和AArch32。

AArch64中不再使用AArch32中的7種特權模式，而是提出了Exception Levels的概念，包括：

1）EL0：用於用戶態程序，許可權最低

2）EL1：給內核使用，許可權稍高

3）EL2：虛擬化相關，許可權更高

4）EL3：安全相關，許可權最高

Linux內核中一般只使用EL0和EL1。

AArch64異常向量表中的異常包括：

1）Synchronous exception（同步異常）

2）SError

3）IRQ

4）FIQ

註：SError、IRQ和FIQ屬於非同步異常。

在Linux內核中，在 arch/arm64/kernel/entry.S 文件中定義了異常向量表，內容如下：

選取 el1_irq() 函數介紹Linux內核中斷的調用流程。

文件： arch/arm64/kernel/entry.S ，調用流程如下：

1、handle_irq()初始化

在 DTS 解析階段完成 handle_irq() 函數的初始化，流程如下：

gic_irq_domain_map() 函數中完成了 handle_irq() 函數的賦值，具體執行如下：

2、handle_irq()實現

以共享外設中斷 SPI 的中斷處理函數 handle_fasteoi_irq() 為例，繼續跟蹤中斷的執行過程。

handle_irq_event_percpu() 函數會調用已經注冊的中斷處理函數，同時喚醒 irq_thread 線程。

3、中斷處理線程

在使用 request_threaded_irq() 函數申請中斷時，會創建一個 irq_thread 線程，調用流程如下：

irq_thread 線程平時在睡眠狀態，等待 handle_irq_event_percpu() 函數喚醒，進一步執行已注冊的中斷處理線程函數。

使用 DRM 框架中 HDMI 中斷驗證中斷調用流程。

文件： driversgpudrmridgesynopsysdw-hdmi.c

在中斷處理函數 dw_hdmi_hardirq() 和中斷處理線程函數 dw_hdmi_irq 中增加 mp_stack() 調用（ 註：僅限於調試驗證 ）。

插入 HDMI 線，系統啟動後，顯示中斷調用流程的日誌如下：

和

㈢ linux驅動中斷，程序運行幾個小時後系統崩潰

中斷與定時器:
中斷的概念:指CPU在執行過程中，出現某些突發事件急待處理，CPU暫停執行當前程序，轉去處理突發事件
，處理完後CPU又返回原程序被中斷的位置繼續執行
中斷的分類:內部中斷和外部中斷
內部中斷:中斷源來自CPU內部(軟體中斷指令、溢出、觸發錯誤等)
外部中斷:中斷源來自CPU外部，由外設提出請求

屏蔽中斷和不可屏蔽中斷:
可屏蔽中斷:可以通過屏蔽字被屏蔽，屏蔽後，該中斷不再得到響應
不可平布中斷:不能被屏蔽

向量中斷和非向量中斷:
向量中斷:CPU通常為不同的中斷分配不同的中斷號，當檢測到某中斷號的中斷到來後，就自動跳轉到與該中斷號對應的地址執行
非向量中斷:多個中斷共享一個入口地址。進入該入口地址後再通過軟體判斷中斷標志來識別具體哪個是中斷
也就是說向量中斷由軟體提供中斷服務程序入口地址，非向量中斷由軟體提供中斷入口地址

/*典型的非向量中斷首先會判斷中斷源，然後調用不同中斷源的中斷處理程序*/
irq_handler()
{
...
int int_src = read_int_status();/*讀硬體的中斷相關寄存器*/
switch(int_src){//判斷中斷標志
case DEV_A:
dev_a_handler();
break;
case DEV_B:
dev_b_handler();
break;
...
default:
break;
}
...
}

定時器中斷原理:
定時器在硬體上也以來中斷，PIT(可編程間隔定時器)接收一個時鍾輸入，
當時鍾脈沖到來時，將目前計數值增1並與已經設置的計數值比較，若相等，證明計數周期滿，產生定時器中斷，並
復位計數值。

如下圖所示:

Linux中斷處理程序架構:
Linux將中斷分為:頂半部(top half)和底半部(bottom half)
頂板部:完成盡可能少的比較緊急的功能，它往往只是簡單的讀取寄存器中的中斷狀態並清除中斷標志後就進行
「登記中斷」(也就是將底半部處理程序掛在到設備的底半部執行隊列中)的工作
特點：響應速度快

底半部:中斷處理的大部分工作都在底半部，它幾乎做了中斷處理程序的所有事情。
特點：處理相對來說不是非常緊急的事件

小知識:Linux中查看/proc/interrupts文件可以獲得系統中斷的統計信息。

如下圖所示:

第一列是中斷號 第二列是向CPU產生該中斷的次數

介紹完相關基礎概念後，讓我們一起來探討一下Linux中斷編程

Linux中斷編程:
1.申請和釋放中斷
申請中斷:
int request_irq(unsigned int irq,irq_handler_t handler,
unsigned long irqflags,const char *devname,void *dev_id)
參數介紹:irq是要申請的硬體中斷號
handler是向系統登記的中斷處理程序(頂半部)，是一個回調函數，中斷發生時，系統調用它，將
dev_id參數傳遞給它
irqflags:是中斷處理的屬性,可以指定中斷的觸發方式和處理方式:
觸發方式:IRQF_TRIGGER_RISING、IRQF_TRIGGER_FALLING、IRQF_TRIGGER_HIGH、IRQF_TRIGGER_LOW
處理方式:IRQF_DISABLE表明中斷處理程序是快速處理程序，快速處理程序被調用時屏蔽所有中斷
IRQF_SHARED表示多個設備共享中斷,dev_id在中斷共享時會用到，一般設置為NULL

返回值:為0表示成功，返回-EINVAL表示中斷號無效，返回-EBUSY表示中斷已經被佔用，且不能共享
頂半部的handler的類型irq_handler_t定義為
typedef irqreturn_t (*irq_handler_t)(int,void*);
typedef int irqreturn_t;

2.釋放IRQ
有請求當然就有釋放了
void free_irq(unsigned int irq,void *dev_id);
參數定義與request_irq類似

3.使能和屏蔽中斷
void disable_irq(int irq);//等待目前中斷處理完成(最好別在頂板部使用，你懂得)
void disable_irq_nosync(int irq);//立即返回
void enable_irq(int irq);//

4.屏蔽本CPU內所有中斷:
#define local_irq_save(flags)...//禁止中斷並保存狀態
void local_irq_disable(void);//禁止中斷，不保存狀態

下面來分別介紹一下頂半部和底半部的實現機制

底半部機制:
簡介:底半部機制主要有tasklet、工作隊列和軟中斷
1.底半部是想方法之一tasklet
(1)我們需要定義tasklet機器處理器並將兩者關聯
例如:
void my_tasklet_func(unsigned long);/*定義一個處理函數*/
DECLARE_TASKLET(my_tasklet,my_tasklet_func,data);
/*上述代碼定義了名為my_tasklet的tasklet並將其餘
my_tasklet_func()函數綁定，傳入的參數為data*/
(2)調度
tasklet_schele(&my_tasklet);
//使用此函數就能在是當的時候進行調度運行

tasklet使用模板:
/*定義tasklet和底半部函數並關聯*/
void xxx_do_tasklet(unsigned long);
DECLARE_TASKLET(xxx_tasklet,xxx_do_tasklet,0);

/*中斷處理底半部*/
void xxx_do_tasklet(unsigned long)
{
...
}

/*中斷處理頂半部*/
irqreturn_t xxx_interrupt(int irq,void *dev_id)
{
...
tasklet_schele(&xxx_tasklet);//調度地板部
...
}

/*設備驅動模塊載入函數*/
int __init xxx_init(void)
{
...
/*申請中斷*/
result = request_irq(xxx_irq,xxx_interrupt,
IRQF_DISABLED,"xxx",NULL);
...

return IRQ_HANDLED;
}

/*設備驅動模塊卸載函數*/
void __exit xxx_exit(void)
{
...
/*釋放中斷*/
free_irq(xxx_irq,xxx_interrupt);
...
}

2.底半部實現方法之二---工作隊列
使用方法和tasklet類似
相關操作:
struct work_struct my_wq;/*定義一個工作隊列*/
void my_wq_func(unsigned long);/*定義一個處理函數*/
通過INIT_WORK()可以初始化這個工作隊列並將工作隊列與處理函數綁定
INIT_WORK(&my_wq,(void (*)(void *))my_wq_func,NULL);
/*初始化工作隊列並將其與處理函數綁定*/
schele_work(&my_wq);/*調度工作隊列執行*/

/*工作隊列使用模板*/

/*定義工作隊列和關聯函數*/
struct work_struct(unsigned long);
void xxx_do_work(unsigned long);

/*中斷處理底半部*/
void xxx_do_work(unsigned long)
{
...
}

/*中斷處理頂半部*/
/*中斷處理頂半部*/
irqreturn_t xxx_interrupt(int irq,void *dev_id)
{
...
schele_work(&my_wq);//調度底半部
...
return IRQ_HANDLED;
}

/*設備驅動模塊載入函數*/
int xxx_init(void)
{
...
/*申請中斷*/
result = request_irq(xxx_irq,xxx_interrupt,
IRQF_DISABLED,"xxx",NULL);
...
/*初始化工作隊列*/
INIT_WORK(&my_wq,(void (*)(void *))xxx_do_work,NULL);
}

/*設備驅動模塊卸載函數*/
void xxx_exit(void)
{
...
/*釋放中斷*/
free_irq(xxx_irq,xxx_interrupt);
...
}

㈣ linux系統中的中斷指令是什麼

什麼是中斷
Linux 內核需要對連接到計算機上的所有硬體設備進行管理，毫無疑問這是它的份內事。如果要管理這些設備，首先得和它們互相通信才行，一般有兩種方案可實現這種功能：
輪詢（polling） 讓內核定期對設備的狀態進行查詢，然後做出相應的處理；中斷（interrupt） 讓硬體在需要的時候向內核發出信號（變內核主動為硬體主動）。
第一種方案會讓內核做不少的無用功，因為輪詢總會周期性的重復執行，大量地耗用 CPU 時間，因此效率及其低下，所以一般都是採用第二種方案 。
對於中斷的理解我們先看一個生活中常見的例子:QQ。第一種情況:你正在工作,然後你的好友突然給你發送了一個窗口抖動,打斷你正在進行的工作。第
二種情況:當然你有時候也會每隔 5 分鍾就去檢查一下 QQ
看有沒有好友找你,雖然這很浪費你的時間。在這里,一次窗口抖動就可以被相當於硬體的中斷,而你就相當於 CPU,你的工作就是 CPU
這在執行的進程。而定時查詢就被相當於 CPU 的輪詢。在這里可以看到:同樣作為 CPU 和硬體溝通的方式,中斷是硬體主動的方式,較輪詢(CPU
主動)更有效些,因為我們都不可能一直無聊到每隔幾分鍾就去查一遍好友列表。
CPU
有大量的工作需要處理,更不會做這些大量無用功。當然這只是一般情況下。好了,這里又有了一個問題,每個硬體設備都中斷,那麼如何區分不同硬體呢?不同設
備同時中斷如何知道哪個中斷是來自硬碟、哪個來自網卡呢?這個很容易,不是每個 QQ 號碼都不相同嗎?同樣的,系統上的每個硬體設備都會被分配一個
IRQ 號,通過這個唯一的 IRQ 號就能區別張三和李四了。
從物理學的角度看，中斷是一種電信號，由硬體設備產生，並直接送入中斷控制器（如
8259A）的輸入引腳上，然後再由中斷控制器向處理器發送相應的信號。處理器一經檢測到該信號，便中斷自己當前正在處理的工作，轉而去處理中斷。此後，
處理器會通知 OS 已經產生中斷。這樣，OS
就可以對這個中斷進行適當的處理。不同的設備對應的中斷不同，而每個中斷都通過一個唯一的數字標識，這些值通常被稱為中斷請求線。

㈤ Linux-怎麼理解軟中斷

中斷是系統用來響應硬體設備請求的一種機制，它會打斷進程的正常調度和執行，然後調用內核中的中斷處理程序來響應設備的請求。

你可能要問了，為什麼要有中斷呢？我可以舉個生活中的例子，讓感受一下中斷的魅力。

比如你訂了一份外賣，但是不確定外賣什麼時候送到，也沒有別的方法了解外賣的進度，但是，配送員送外賣是不等人的，到了你這兒沒人取的話，就直接走人了，所以你只能苦苦等著，時不時去門口看看外賣送到沒，而不能幹其他事情。

不過呢，如果在訂外賣的時候，你就跟配送員約定好，讓他送到後給你打個電話，那你就不用苦苦等待了，就可以去忙別的事情，直到電話一響，接電話、取外賣就可以了。

這里的「打電話」，其實就是一個中斷。沒接到電話的時候，你可以做其他的事情；只有接到了電話（也就是發生中斷），你才要進行另一個動作：取外賣。

這個例子你就可以發現， 中斷其實是一種非同步的事件處理機制，可以提高系統的並發處理能力。

由於中斷處理程序會打斷其他進程的運行，所以， 為了減少對正常進程運行調度的影響，中斷處理程序就需要盡可能快地運行。 如果中斷本身要做的事情不多，那麼處理起來也不會有太大問題；但如果中斷要處理的事情很多，中斷服務程序就有可能要運行很長時間。

特別是，中斷處理程序在響應中斷時，還會臨時關閉中斷。這就會導致上一次中斷處理完成之前，其他中斷都不能響應，也就是說中斷有可能會丟失。

那麼還是以取外賣為例。假如你訂了 2 份外賣，一份主食和一份飲料，並且是由 2 個不同的配送員來配送。這次你不用時時等待著，兩份外賣都約定了電話取外賣的方式。但是，問題又來了。

當第一份外賣送到時，配送員給你打了個長長的電話，商量發票的處理方式。與此同時，第二個配送員也到了，也想給你打電話。

但是很明顯，因為電話占線（也就是關閉了中斷響應），第二個配送員的電話是打不通的。所以，第二個配送員很可能試幾次後就走掉了（也就是丟失了一次中斷）。

如果你弄清楚了「取外賣」的模式，那對系統的中斷機制就很容易理解了。事實上，為了解決中斷處理程序執行過長和中斷丟失的問題，Linux 將中斷處理過程分成了兩個階段，也就是 上半部和下半部：

比如說前面取外賣的例子，上半部就是你接聽電話，告訴配送員你已經知道了，其他事兒見面再說，然後電話就可以掛斷了；下半部才是取外賣的動作，以及見面後商量發票處理的動作。

這樣，第一個配送員不會佔用你太多時間，當第二個配送員過來時，照樣能正常打通你的電話。

除了取外賣，我再舉個最常見的網卡接收數據包的例子，讓你更好地理解。

網卡接收到數據包後，會通過 硬體中斷 的方式，通知內核有新的數據到了。這時，內核就應該調用中斷處理程序來響應它。你可以自己先想一下，這種情況下的上半部和下半部分別負責什麼工作呢？

對上半部來說，既然是快速處理，其實就是要把網卡的數據讀到內存中，然後更新一下硬體寄存器的狀態（表示數據已經讀好了），最後再發送一個 軟中斷 信號，通知下半部做進一步的處理。

而下半部被軟中斷信號喚醒後，需要從內存中找到網路數據，再按照網路協議棧，對數據進行逐層解析和處理，直到把它送給應用程序。

所以，這兩個階段你也可以這樣理解：

實際上，上半部會打斷 CPU 正在執行的任務，然後立即執行中斷處理程序。而下半部以內核線程的方式執行，並且每個 CPU 都對應一個軟中斷內核線程，名字為 「ksoftirqd/CPU 編號」，比如說， 0 號 CPU 對應的軟中斷內核線程的名字就是 ksoftirqd/0。

不過要注意的是，軟中斷不只包括了剛剛所講的硬體設備中斷處理程序的下半部，一些內核自定義的事件也屬於軟中斷，比如內核調度和 RCU 鎖（Read-Copy Update 的縮寫，RCU 是 Linux 內核中最常用的鎖之一）等。

不知道你還記不記得，前面提到過的 proc 文件系統。它是一種內核空間和用戶空間進行通信的機制，可以用來查看內核的數據結構，或者用來動態修改內核的配置。其中：

運行下面的命令，查看 /proc/softirqs 文件的內容，你就可以看到各種類型軟中斷在不同 CPU 上的累積運行次數：

在查看 /proc/softirqs 文件內容時，你要特別注意以下這兩點。
第一，要注意軟中斷的類型，也就是這個界面中第一列的內容。從第一列你可以看到，軟中斷包括了 10 個類別，分別對應不同的工作類型。比如 NET_RX 表示網路接收中斷，而 NET_TX 表示網路發送中斷。

第二，要注意同一種軟中斷在不同 CPU 上的分布情況，也就是同一行的內容。正常情況下，同一種中斷在不同 CPU 上的累積次數應該差不多。比如這個界面中，NET_RX 在 CPU0 和 CPU1 上的中斷次數基本是同一個數量級，相差不大。

不過你可能發現，TASKLET 在不同 CPU 上的分布並不均勻。TASKLET 是最常用的軟中斷實現機制，每個 TASKLET 只運行一次就會結束 ，並且只在調用它的函數所在的 CPU 上運行。

因此，使用 TASKLET 特別簡便，當然也會存在一些問題，比如說由於只在一個 CPU 上運行導致的調度不均衡，再比如因為不能在多個 CPU 上並行運行帶來了性能限制。

另外，剛剛提到過，軟中斷實際上是以內核線程的方式運行的，每個 CPU 都對應一個軟中斷內核線程，這個軟中斷內核線程就叫做 ksoftirqd/CPU 編號。那要怎麼查看這些線程的運行狀況呢？

其實用 ps 命令就可以做到，比如執行下面的指令：

注意，這些線程的名字外面都有中括弧，這說明 ps 無法獲取它們的命令行參數（cmline）。一般來說，ps 的輸出中，名字括在中括弧里的，一般都是內核線程。

Linux 中的中斷處理程序分為上半部和下半部：
上半部對應硬體中斷，用來快速處理中斷。
下半部對應軟中斷，用來非同步處理上半部未完成的工作。

Linux 中的軟中斷包括網路收發、定時、調度、RCU 鎖等各種類型，可以通過查看 /proc/softirqs 來觀察軟中斷的運行情況。

㈥ linux 內核軟中斷 是在中斷狀態嗎

先說說環境
1.硬體:DELL R410
2.網卡:板載1000M BCM5709
2.OS: RHEL 5.5 x86_64
3.KERNEL: 2.6.18-194.el5
所出現的問題
1.網卡毫無徵兆的down掉，而且沒有任何log信息
2.當流量增大時，不到理論上限的1/3時機器出現網路延遲嚴重，伴隨大量的丟包
3.機器的cpu軟中斷不均衡，只有1個cpu處理軟中斷，並且該cpu的軟中斷周期性的達到100%
4.內外網網卡做nat丟包數據量不一致，差別很大，不在同一個數量級
想必第一個問題，大部分使用bcm網卡，rhel 5.3以後得機器都會遇到這種情況，網上的資料比較的多，我也不多啰嗦了，直接升級網卡驅動就可以解決了。第二，三，四其實是同一個問題都是由於網卡中斷過多，cpu處理不過來(准確的說，cpu分配不均衡，導致只有一個cpu處理，處理不過來)，引起丟包，那麼為什麼兩個網卡丟包的數量級不一樣呢，下面從原理上進行解釋，既然是做nat多出口，那麼就有大量的路由信息，是一個網路應用，當一個數據包請求nat時，數據包先被網卡驅動的數據接收，網卡收到數據時，觸發中斷。在中斷執行常式中，把skb掛入輸入隊列，並觸發軟中斷。稍後的某個時刻，當軟中斷執行時，再從該隊列中把skb取下來，投遞給上層協議。
如果在這個過程當中cpu沒有及時處理完這個隊列導致網卡的buffer滿了，網卡將直接丟棄該數據包。這里牽涉到2個隊列，一個是tx，一個是rx，它的隊列的大小默認都是255，可以通過ethtool -g eth0(你指定的網卡)，為了防止丟包，當時我通過ethtool -G eth0 rx xxx 把它調大了，但是調大以後，還是杯水車薪啊，通過ethtool -S eth0 |grep rx_fw_discards,發現數值還是不停的在增長，也就是說還在不停的丟包，cpu處理不過來，這時候找到網上有人在利用lvs時也遇到這個問題，cpu軟中斷分配不均衡，只有一個cpu處理軟中斷的問題，網上的資料五花八門，有建議使用修改設備中斷方式。即通過修改設置中斷/proc/irq/${網卡中斷號}/smp_affinit這時候，我也修改過，沒有什麼實質的效果，
從官方的bug報告，https://bugzilla.redhat.com/show_bug.cgi?id=520888，其中提到rhel5.6已經修復了這個bug，這其中也提到目前我們的版本可以升級內核到kernel-2.6.18-194.3.1.el5可以解決這個問題。
紅帽子官方修復報告中的說明如下：http://rhn.redhat.com/errata/RHSA-2010-0398.html，我們升級了這個內核算是解決單核處理軟中斷的問題，升級後各個cpu已經能夠平均的分配這個軟中斷，也不丟包了，那麼為什麼cpu處理不過來這個軟中斷呢，數據量並不是特別的大啊，上層應用接到這個數據包後，通過路由協議，找到某個出口給nat出去，找nat出口是需要查找路由表，查詢路由表是一件很耗時的工作，而每一個不同源地址，不同目的地址的數據包都得重新查找一次路由表，導致cpu處理不過來，為了提高路由查詢的效率。Linux內核引用了路由緩存，用於減少對路由表的查詢。Linux的路由緩存是被設計來與協議無關的獨立子系統，查看路由緩存可以通過命令route -Cn,由於路由緩存當中是採用hash演算法進行才找，它的查找速度非常之快，既然是cache就有超時這一概念。系統默認為10分鍾，可以通過這個文件進行查看和修改/proc/sys/net/ipv4/route/secret_interval。而當路由緩存當中未找到或者已經超時的路由信息才開始查找路由表，查詢到的結果保存在路由緩存中。如果路由表越大，那麼查詢的時間就越長，一個新的連接進來後或者是老連接cache超時後，佔用大量的cpu查詢時間，導致cpu周期性的軟中斷出現100%，而兩個網卡丟包的情況來看不均衡也是因為用戶的數據包是經過其中一個網卡進來後查詢路由表耗時過長，cpu處理不過來，導致那塊網卡的隊列滿了，丟包嚴重。當然在路由表變動不大的情況下可以加大cache的時間，修改上述內容後，從我監測的情況來看，扛流量能力得到了大大的提升。

㈦ Linux中斷與定時器

所謂中斷是指CPU在執行程序的過程中，出現了某些突發事件急待處理，CPU必須暫停當前程序的執行，轉去處理突發事件，處理完畢後又返回原程序被中斷的位置繼續執行。根據中斷的來源，中斷可分為內部中斷和外部中斷，內部中斷的中斷源來自CPU內部（軟體中斷指令、溢出、除法錯誤等，例如，操作系統從用戶態切換到內核態需藉助CPU內部的軟體中斷），外部中斷的中斷源來自CPU外部，由外設提出請求。根據中斷是否可以屏蔽，中斷可分為可屏蔽中斷與不可屏蔽中斷（NMI），可屏蔽中斷可以通過設置中斷控制器寄存器等方法被屏蔽，屏蔽後，該中斷不再得到響應，而不可屏蔽中斷不能被屏蔽。
根據中斷入口跳轉方法的不同，中斷可分為向量中斷和非向量中斷。採用向量中斷的CPU通常為不同的中斷分配不同的中斷號，當檢測到某中斷號的中斷到來後，就自動跳轉到與該中斷號對應的地址執行。不同中斷號的中斷有不同的入口地址。非向量中斷的多個中斷共享一個入口地址，進入該入口地址後，再通過軟體判斷中斷標志來識別具體是哪個中斷。也就是說，向量中斷由硬體提供中斷服務程序入口地址，非向量中斷由軟體提供中斷服務程序入口地址。
嵌入式系統以及x86PC中大多包含可編程中斷控制器（PIC），許多MCU內部就集成了PIC。如在80386中，PIC是兩片i8259A晶元的級聯。通過讀寫PIC的寄存器，程序員可以屏蔽/使能某中斷及獲得中斷狀態，前者一般通過中斷MASK寄存器完成，後者一般通過中斷PEND寄存器完成。定時器在硬體上也依賴中斷來實現，典型的嵌入式微處理器內可編程間隔定時器（PIT）的工作原理，它接收一個時鍾輸入，當時鍾脈沖到來時，將目前計數值增1並與預先設置的計數值（計數目標）比較，若相等，證明計數周期滿，並產生定時器中斷且復位目前計數值。

㈧ linux中斷的下半部機制有哪些

一、中斷處理為什麼要下半部？Linux在中斷處理中間中斷處理分了上半部和下半部，目的就是提高系統的響應能力和並發能力。通俗一點來講：當一個中斷產生，調用該中斷對應的處理程序(上半部)然後告訴系統，對應的後半部可以執行了。然後中斷處理程序就返回，下半部會在合適的時機有系統調用。這樣一來就大大的減少了中斷處理所需要的時間。

二、那些工作應該放在上半部，那些應該放在下半部？
沒有嚴格的規則，只有一些提示：
1、對時間非常敏感，放在上半部。
2、與硬體相關的，放在上半部。
3、不能被其他中斷打斷的工作，放在上半部。
以上三點之外的，考慮放在下半部。

三、下半部機制在Linux中是怎麼實現的？
下半部在Linux中有以下實現機制：
1、BH(在2.5中刪除)
2、任務隊列(task queue，在2.5刪除)
3、軟中斷(softirq，2.3開始。本文重點)
4、tasklet(2.3開始)
5、工作隊列(work queue，2.5開始)

四、軟中斷是怎麼實現的(以下代碼出自2.6.32)？
軟中斷不會搶占另外一個軟中斷，唯一可以搶占軟中斷的是中斷處理程序。
軟中斷可以在不同CPU上並發執行(哪怕是同一個軟中斷)

1、軟中斷是編譯期間靜態分配的，定義如下：
struct softirq_action { void (*action)(struct softirq_action *); };

/*
* PLEASE, avoid to allocate new softirqs, if you need not _really_ high
* frequency threaded job scheling. For almost all the purposes
* tasklets are more than enough. F.e. all serial device BHs et
* al. should be converted to tasklets, not to softirqs.
*/
enum {
HI_SOFTIRQ=0,
TIMER_SOFTIRQ,
NET_TX_SOFTIRQ,
NET_RX_SOFTIRQ,
BLOCK_SOFTIRQ,
BLOCK_IOPOLL_SOFTIRQ,
TASKLET_SOFTIRQ,
SCHED_SOFTIRQ,
HRTIMER_SOFTIRQ,
RCU_SOFTIRQ, /* Preferable RCU should always be the last softirq */
NR_SOFTIRQS