linux軟中斷cpu

Ⅰ 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
};

/*
* map softirq index to softirq name. update 'softirq_to_name' in * kernel/softirq.c when adding a new softirq.
*/
extern char *softirq_to_name[NR_SOFTIRQS];

static struct softirq_action softirq_vec[NR_SOFTIRQS] __cacheline_aligned_in_smp;

說明：
(1)、軟中斷的個數書上說是32，看來到這個版本已經發生變化了。
(2)、void (*action)(struct softirq_action *);傳遞整個結構體指針在於當結構體成員發生變化是，介面不變。

2、系統執行軟中斷一個注冊的軟中斷必須被標記後才會執行(觸發軟中斷)，通常中斷處理程序會在返回前標記它的軟中斷。在下列地方，待處理的軟中斷會被執行：
(1)、從一個硬體中斷代碼處返回。
(2)、在ksoftirqd內核線程。
(3)、在那些顯示檢查和執行待處理的軟中斷代碼中。

ksoftirqd說明：
每個處理器都有一個這樣的線程。所有線程的名字都叫做ksoftirq/n，區別在於n，它對應的是處理器的編號。在一個雙CPU的機器上就有兩個這樣的線程，分別叫做ksoftirqd/0和ksoftirqd/1。為了保證只要有空閑的處理器，它們就會處理軟中斷，所以給每個處理器都分配一個這樣的線程。

執行軟中斷的代碼如下：
asmlinkage void __do_softirq(void)
{
struct softirq_action *h;
__u32 pending;
int max_restart = MAX_SOFTIRQ_RESTART;
int cpu;

pending = local_softirq_pending();
account_system_vtime(current);

__local_bh_disable((unsigned long)__builtin_return_address(0));
lockdep_softirq_enter();

cpu = smp_processor_id();
restart:
/* Reset the pending bitmask before enabling irqs */
set_softirq_pending(0);

local_irq_enable();

h = softirq_vec;

do {
if (pending & 1) {
int prev_count = preempt_count();
kstat_incr_softirqs_this_cpu(h - softirq_vec);

trace_softirq_entry(h, softirq_vec);
h->action(h);
trace_softirq_exit(h, softirq_vec);
if (unlikely(prev_count != preempt_count())) {
printk(KERN_ERR "huh, entered softirq %td %s %p"
"with preempt_count %08x,"
" exited with %08x?\n", h - softirq_vec,
softirq_to_name[h - softirq_vec],
h->action, prev_count, preempt_count());
preempt_count() = prev_count;
}

rcu_bh_qs(cpu);
}
h++;
pending >>= 1;
} while (pending);

local_irq_disable();

pending = local_softirq_pending();
if (pending && --max_restart)
goto restart;

if (pending)
wakeup_softirqd();

lockdep_softirq_exit();

account_system_vtime(current);
_local_bh_enable();
}

3、編寫自己的軟中斷
(1)、分配索引，在HI_SOFTIRQ與NR_SOFTIRQS中間添加自己的索引號。
(2)、注冊處理程序，處理程序：open_softirq(索引號，處理函數)。
(3)、觸發你的軟中斷：raise_softirq(索引號)。

4、軟中斷處理程序注意
(1)、軟中斷處理程序執行的時候，允許響應中斷，但自己不能休眠。
(2)、如果軟中斷在執行的時候再次觸發，則別的處理器可以同時執行，所以加鎖很關鍵。

Ⅱ 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的時間，修改上述內容後，從我監測的情況來看，扛流量能力得到了大大的提升。

Ⅲ 軟中斷的概念

軟中斷是利用硬體中斷的概念，用軟體方式進行模擬，實現宏觀上的非同步執行效果。很多情況下，軟中斷和信號有些類似，同時，軟中斷又是和硬中斷相對應的，硬中斷是外部設備對CPU的中斷，軟中斷通常是硬中斷服務程序對內核的中斷，信號則是由內核（或其他進程）對某個進程的中斷（《Linux內核源代碼情景分析》第三章）。
軟中斷是linux系統原「底半處理」的升級，在原有的基礎上發展的新的處理方式，以適應多cpu 、多線程的軟中斷處理。
軟中斷是實現系統API函數調用的手段
函數調用時將返回地址和CPU狀態寄存器內容壓棧，函數執行完畢後出棧返回斷點繼續執行。
軟中斷調用時將返回地址和CPU狀態寄存器內容壓棧，修改特權級，根據中斷號查找中斷向量表，找到ISR中斷服務常式地址，跳轉執行。
綜上，函數調用和軟中斷調用的區別是，軟中斷多了修改特權級和查找中斷向量表的功能，其他部分完全一樣。
一般，系統程序由軟體公司實現且不開源，你無法知道系統API函數的偏移地址，而且你寫的應用程序和軟體公司提供的系統程序是完全分開的，編譯器無法將二者鏈接在一起，同時，系統程序需要核心態特權才能運行，此時用函數調用的辦法是無法調用系統API函數的。解決這個問題的方法是使用軟中斷，當應用程序需要調用API時，就先設置功能號(如AX=0H)，然後觸發軟中斷(如INT 80H)。系統程序設置好中斷向量表。這樣，應用程序就可以間接找到系統API了。
有了軟中斷，就可以實現應用程序的動態載入。就像WINDOWS/Linux那樣，應用程序和系統程序分別開發，不在一起編譯連接，應用程序通過軟中斷調用系統提供的功能。

Ⅳ LINUX軟中斷通信

我也是初學者，這里抄一段《Linux設備驅動程序》書上的給你：

Linux的中斷宏觀分為兩種：軟中斷和硬中斷。聲明一下，這里的軟和硬的意思是指和軟體相關以及和硬體相關，而不是軟體實現的中斷或硬體實現的中斷。軟中斷就是「信號機制」。軟中斷不是軟體中斷。Linux通過信號來產生對進程的各種中斷操作，我們現在知道的信號共有31個，其具體內容這里略過。
一般來說，軟中斷是由內核機制的觸發事件引起的（例如進程運行超時），但是不可忽視有大量的軟中斷也是由於和硬體有關的中斷引起的，例如當列印機埠產生一個硬體中斷時，會通知和硬體相關的硬中斷，硬中斷就會產生一個軟中斷並送到操作系統內核里，這樣內核就會根據這個軟中斷喚醒睡眠在列印機任務隊列中的處理進程。
硬中斷就是通常意義上的「中斷處理程序」，它是直接處理由硬體發過來的中斷信號的。當硬中斷收到它應當處理的中斷信號以後，就回去自己驅動的設備上去看看設備的狀態寄存器以了解發生了什麼事情，並進行相應的操作。
對於軟中斷，我們不做討論，那是進程調度里要考慮的事情。由於我們討論的是設備驅動程序的中斷問題，所以焦點集中在硬中斷里。我們這里討論的是硬中斷，即和硬體相關的中斷。
要中斷，是因為外設需要通知操作系統她那裡發生了一些事情，但是中斷的功能僅僅是一個設備報警燈，當燈亮的時候中斷處理程序只知道有事情發生了，但發生了什麼事情還要親自到設備那裡去看才行。也就是說，當中斷處理程序得知設備發生了一個中斷的時候，它並不知道設備發生了什麼事情，只有當它訪問了設備上的一些狀態寄存器以後，才能知道具體發生了什麼，要怎麼去處理。
設備通過中斷線向中斷控制器發送高電平告訴操作系統它產生了一個中斷，而操作系統會從中斷控制器的狀態位知道是哪條中斷線上產生了中斷。PC機上使用的中斷控制器是8259，這種控制器每一個可以管理8條中斷線，當兩個8259級聯的時候共可以控制15條中斷線。這里的中斷線是實實在在的電路，他們通過硬體介面連接到CPU外的設備控制器上。
並不是每個設備都可以向中斷線上發中斷信號的，只有對某一條確定的中斷線勇有了控制權，才可以向這條中斷線上發送信號。由於計算機的外部設備越來越多，所以15條中斷線已經不夠用了，中斷線是非常寶貴的資源。要使用中斷線，就得進行中斷線的申請，就是IRQ(Interrupt Requirement)，我們也常把申請一條中斷線成為申請一個IRQ或者是申請一個中斷號。
IRQ是非常寶貴的，所以我們建議只有當設備需要中斷的時候才申請佔用一個IRQ，或者是在申請IRQ時採用共享中斷的方式，這樣可以讓更多的設備使用中斷。無論對IRQ的使用方式是獨占還是共享，申請IRQ的過程都是一樣的，分為3步：
1．將所有的中斷線探測一遍，看看哪些中斷還沒有被佔用。從這些還沒有被佔用的中斷中選一個作為該設備的IRQ。
2．通過中斷申請函數申請選定的IRQ，這是要指定申請的方式是獨占還是共享。
3．根據中斷申請函數的返回值決定怎麼做：如果成功了萬事大吉，如果沒成功則或者重新申請或者放棄申請並返回錯誤。
Linux中的中斷處理程序很有特色，它的一個中斷處理程序分為兩個部分：上半部（top half）和下半部(bottom half)。之所以會有上半部和下半部之分，完全是考慮到中斷處理的效率。
上半部的功能是「登記中斷」。當一個中斷發生時，他就把設備驅動程序中中斷常式的下半部掛到該設備的下半部執行隊列中去，然後就沒事情了--等待新的中斷的到來。這樣一來，上半部執行的速度就會很快，他就可以接受更多她負責的設備產生的中斷了。上半部之所以要快，是因為它是完全屏蔽中斷的，如果她不執行完，其它的中斷就不能被及時的處理，只能等到這個中斷處理程序執行完畢以後。所以，要盡可能多得對設備產生的中斷進行服務和處理，中斷處理程序就一定要快。
但是，有些中斷事件的處理是比較復雜的，所以中斷處理程序必須多花一點時間才能夠把事情做完。可怎麼樣化解在短時間內完成復雜處理的矛盾呢，這時候 Linux引入了下半部的概念。下半部和上半部最大的不同是下半部是可中斷的，而上半部是不可中斷的。下半部幾乎做了中斷處理程序所有的事情，因為上半部只是將下半部排到了他們所負責的設備的中斷處理隊列中去，然後就什麼都不管了。下半部一般所負責的工作是察看設備以獲得產生中斷的事件信息，並根據這些信息（一般通過讀設備上的寄存器得來）進行相應的處理。如果有些時間下半部不知道怎麼去做，他就使用著名的鴕鳥演算法來解決問題--說白了就是忽略這個事件。
由於下半部是可中斷的，所以在它運行期間，如果其它的設備產生了中斷，這個下半部可以暫時的中斷掉，等到那個設備的上半部運行完了，再回頭來運行它。但是有一點一定要注意，那就是如果一個設備中斷處理程序正在運行，無論她是運行上半部還是運行下半部，只要中斷處理程序還沒有處理完畢，在這期間設備產生的新的中斷都將被忽略掉。因為中斷處理程序是不可重入的，同一個中斷處理程序是不能並行的。
在Linux Kernel 2.0以前，中斷分為快中斷和慢中斷（偽中斷我們這里不談），其中快中斷的下半部也是不可中斷的，這樣可以保證它執行的快一點。但是由於現在硬體水平不斷上升，快中斷和慢中斷的運行速度已經沒有什麼差別了，所以為了提高中斷常式事務處理的效率，從Linux kernel 2.0以後，中斷處理程序全部都是慢中斷的形式了--他們的下半部是可以被中斷的。
但是，在下半部中，你也可以進行中斷屏蔽--如果某一段代碼不能被中斷的話。你可以使用cti、sti或者是save_flag、restore_flag來實現你的想法。
在處理中斷的時候，中斷控制器會屏蔽掉原先發送中斷的那個設備，直到她發送的上一個中斷被處理完了為止。因此如果發送中斷的那個設備載中斷處理期間又發送了一個中斷，那麼這個中斷就被永遠的丟失了。
之所以發生這種事情，是因為中斷控制器並不能緩沖中斷信息，所以當前一個中斷沒有處理完以前又有新的中斷到達，他肯定會丟掉新的中斷的。但是這種缺陷可以通過設置主處理器(CPU)上的「置中斷標志位」（sti）來解決，因為主處理器具有緩沖中斷的功能。如果使用了「置中斷標志位」，那麼在處理完中斷以後使用sti函數就可以使先前被屏蔽的中斷得到服務。
有時候需要屏蔽中斷，可是為什麼要將這個中斷屏蔽掉呢？這並不是因為技術上實現不了同一中斷常式的並行，而是出於管理上的考慮。之所以在中斷處理的過程中要屏蔽同一IRQ來的新中斷，是因為中斷處理程序是不可重入的，所以不能並行執行同一個中斷處理程序。在這里我們舉一個例子，從這里子例中可以看出如果一個中斷處理程序是可以並行的話，那麼很有可能會發生驅動程序鎖死的情況。當驅動程序鎖死的時候，你的操作系統並不一定會崩潰，但是鎖死的驅動程序所支持的那個設備是不能再使用了--設備驅動程序死了，設備也就死了。
A是一段代碼，B是操作設備寄存器R1的代碼，C是操作設備寄存器R2的代碼。其中激發PS1的事件會使A1產生一個中斷，然後B1去讀R1中已有的數據，然後代碼C1向R2中寫數據。而激發PS2的事件會使A2產生一個中斷，然後B2刪除R1中的數據，然後C2讀去R2中的數據。
如果PS1先產生，且當他執行到A1和B1之間的時候，如果PS2產生了，這是A2會產生一個中斷，將PS2中斷掉（掛到任務隊列的尾部），然後刪除了 R1的內容。當PS2運行到C2時，由於C1還沒有向R2中寫數據，所以C2將會在這里被掛起，PS2就睡眠在代碼C2上，直到有數據可讀的時候被信號喚醒。這是由於PS1中的B2原先要讀的R1中的數據被PS2中的B2刪除了，所以PS1頁會睡眠在B1上，直到有數據可讀的時候被信號喚醒。這樣一來，喚醒PS1和PS2的事件就永遠不會發生了，因此PS1和PS2之間就鎖死了。
由於設備驅動程序要和設備的寄存器打交道，所以很難寫出可以重入的代碼來，因為設備寄存器就是全局變數。因此，最簡潔的辦法就是禁止同一設備的中斷處理程序並行，即設備的中斷處理程序是不可重入的。
有一點一定要清楚：在2.0版本以後的Linux kernel中，所有的上半部都是不可中斷的（上半部的操作是原子性的）；不同設備的下半部可以互相中斷，但一個特定的下半部不能被它自己所中斷（即同一個下半部不能並）。
由於中斷處理程序要求不可重入，所以程序員也不必為編寫可重入的代碼而頭痛了。編寫可重入的設備驅動程序是可以的，編寫可重入的中斷處理程序是非常難得，幾乎不可能。
我們都知道，一旦競爭條件出現了，就有可能會發生死鎖的情況，嚴重時可能會將整個系統鎖死。所以一定要避免競爭條件的出現。只要注意一點：絕大多數由於中斷產生的競爭條件，都是在帶有中斷的
內核進程被睡眠造成的。所以在實現中斷的時候，一定要相信謹慎的讓進程睡眠，必要的時候可以使用cli、sti或者save_flag、restore_flag。

Ⅳ 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系統怎麼查看內存和CPU佔用情況呀

1、在電腦中進入Linux操作系統，打開Linux命令界面。

Ⅶ 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

Ⅷ linux系統調用是通過軟中斷實現的嗎

軟中斷是利用硬體中斷的概念，用軟體方式進行模擬，實現宏觀上的非同步執行效果。很多情況下，軟中斷和信號有些類似，同時，軟中斷又是和硬中斷相對應的，硬中斷是外部設備對CPU的中斷，軟中斷通常是硬中斷服務程序對內核的中斷，信號則是由內核（或其他進程）對某個進程的中斷（《Linux內核源代碼情景分析》第三章）。軟中斷是linux系統原「底半處理」的升級，在原有的基礎上發展的新的處理方式，以適應多cpu 、多線程的軟中斷處理。
軟中斷是實現系統API函數調用的手段
函數調用時將返回地址和CPU狀態寄存器內容壓棧，函數執行完畢後出棧返回斷點繼續執行。
軟中斷調用時將返回地址和CPU狀態寄存器內容壓棧，修改特權級，根據中斷號查找中斷向量表，找到ISR中斷服務常式地址，跳轉執行。

Ⅸ linux中查看虛擬內存和cpu佔用率的命令是什麼

top，free，cat/proc/meminfo，cat/proc/cpuinfo。

[root@centerlisdbproc]#dmidecode|grep-A16"MemoryDevice"|more[objectObject]。

查看內存使用情況：cat/proc/meminfo，查看CPU使用情況：cat /proc/cpuinfo。

在系統維護的過程中，隨時可能有需要查看 CPU 使用率，並根據相應信息分析系統狀況的需要。在 CentOS 中，可以通過 top 命令來查看 CPU 使用狀況。

運行 top 命令後，CPU 使用狀態會以全屏的方式顯示，並且會處在對話的模式 -- 用基於 top 的命令，可以控制顯示方式等等。退出 top 的命令為 q （在 top 運行中敲 q 鍵一次）。

top命令是Linux下常用的性能分析工具，能夠實時顯示系統中各個進程的資源佔用狀況，類似於Windows的任務管理器。

可以直接使用top命令後，查看%MEM的內容。可以選擇按進程查看或者按用戶查看，如想查看oracle用戶的進程內存使用情況的話可以使用如下的命令：$ top -u oracle。

(9)linux軟中斷cpu擴展閱讀：

一、查看內存佔用：

1、free

# free -m。

以MB為單位顯示內存使用情況。

# free -h。

以GB為單位顯示內存使用情況。

# free -t。

以總和的形式查詢內存的使用信息。

# free -s 5。

周期性的查詢內存使用信息。

每5秒執行一次命令。

二、查看CPU使用情況：

1、top。

top後鍵入P看一下誰佔用最大。

# top -d 5。

周期性的查詢CPU使用信息。

每5秒刷新一次。

2、ps auxw（查看本機的進程所佔cpu和mem的百分比情況）。

使用"ps auxw" 可以查看到本機的進程所佔cpu和mem的百分比情況。

# ps auxw | head -1

%CPU 進程的cpu佔用率。

%MEM 進程的內存佔用率。

3、查看本機所有進程的CPU佔比之和。

# cat cpu_per.sh

三、查看cpu信息（信息記錄在/proc/cpuinfo中）

# 總核數 = 物理CPU個數 X 每顆物理CPU的核數。

# 總邏輯CPU數 = 物理CPU個數 X 每顆物理CPU的核數 X 超線程數。