linux軟中斷機制分析
軟中斷分析
最近工作繁忙,沒有時間總結核心相關的一些東西。上次更新部落格到了linux核心中斷子系統。這次總結一下軟中斷,也就是softirq。之後還會總結一些tasklet、工作佇列機制。
http://alloysystem.blog.chinaunix.net
Andy.yx.deng#gmail.com(#->@)
1. 為什麼要軟中斷
編寫驅動的時候,一箇中斷產生之後,核心在中斷處理函式中可能需要完成很多工作。但是中斷處理函式的處理是關閉了中斷的。也就是說在響應中斷時,系統不能再次響應外部的其它中斷。這樣的後果會造成有可能丟失外部中斷。於是,linux
關於軟體中斷的理論各種書籍都有介紹,不多敘述。而要真正體會軟體中斷的作用就必須從程式碼的角度來分析。我們做工作時候講求的是professional,當一個人在某個領域一無所知的時候,我們稱他為小白,偶,非蘋果電腦。小白的腦子裡充滿了各種問題。慢慢的當這些疑惑解釋完之後,小白就脫白了。此時,我們對這個領域的基本框架有了解,但這和professional還有一定的差距。再加以時日,逐漸融會貫通該領域才能達到專業的境界。
說了這麼多廢話,趕快步入正題。初識軟中斷,腦子裡肯定有不少的疑問,首先就是軟體中斷在什麼地方被觸發處理?這個問題的答案就是:一個硬體中斷處理完成之後。下面的函式在處理完硬體中斷之後推出中斷處理函式,在irq_exit中會觸發軟體中斷的處理。
這裡要注意,invoke_softirq必須滿足兩個條件才能被呼叫到,一個就是不是在硬體中斷處理過程中或者在軟體中斷處理中,第二個就是必須有軟體中斷處於pending狀態。第二個好理解,有軟體中斷產生才去處理,沒有就不處理。第一個就不好理解了。asmlinkage void __exception asm_do_IRQ(unsigned int irq, struct pt_regs *regs) { struct pt_regs *old_regs = set_irq_regs(regs); irq_enter(); /* * Some hardware gives randomly wrong interrupts. Rather * than crashing, do something sensible. */ if (irq >= NR_IRQS) handle_bad_irq(irq, &bad_irq_desc); else generic_handle_irq(irq); /* AT91 specific workaround */ irq_finish(irq); irq_exit(); set_irq_regs(old_regs); }
/*
* Exit an interrupt context. Process softirqs if needed and possible:
*/
void irq_exit(void)
{
account_system_vtime(current);
trace_hardirq_exit();
sub_preempt_count(IRQ_EXIT_OFFSET);
if (!in_interrupt() && local_softirq_pending())
invoke_softirq();
#ifdef CONFIG_NO_HZ
/* Make sure that timer wheel updates are propagated */
rcu_irq_exit();
if (idle_cpu(smp_processor_id()) && !in_interrupt() && !need_resched())
tick_nohz_stop_sched_tick(0);
#endif
preempt_enable_no_resched();
}
在linux系統的程序資料結構裡,有這麼一個數據結構
#define preempt_count()(current_thread_info()->preempt_count),
利用preempt_count可以表示是否處於中斷處理或者軟體中斷處理過程中。
#define PREEMPT_MASK (__IRQ_MASK(PREEMPT_BITS) << PREEMPT_SHIFT)
#define SOFTIRQ_MASK (__IRQ_MASK(SOFTIRQ_BITS) << SOFTIRQ_SHIFT)
#define HARDIRQ_MASK (__IRQ_MASK(HARDIRQ_BITS) << HARDIRQ_SHIFT)
#define PREEMPT_OFFSET (1UL << PREEMPT_SHIFT)
#define SOFTIRQ_OFFSET (1UL << SOFTIRQ_SHIFT)
#define HARDIRQ_OFFSET (1UL << HARDIRQ_SHIFT)
sub_preempt_count(IRQ_EXIT_OFFSET);
#define in_interrupt() (irq_count())
#define irq_count() (preempt_count() & (HARDIRQ_MASK | SOFTIRQ_MASK))
preempt_count的8~23位記錄中斷處理和軟體中斷處理過程的計數。如果有計數,表示系統在硬體中斷或者軟體中斷處理過程中。系統這麼設計是為了避免軟體中斷在中斷巢狀中被呼叫,並且達到在單個CPU上軟體中斷不能被重入的目的。對於ARM架構的CPU不存在中斷巢狀中呼叫軟體中斷的問題,因為ARM架構的CPU在處理硬體中斷的過程中是關閉掉中斷的。只有在進入了軟中斷處理過程中之後才會開啟硬體中斷,如果在軟體中斷處理過程中有硬體中斷巢狀,也不會再次呼叫軟中斷,because硬體中斷是軟體中斷處理過程中再次進入的,此時preempt_count已經記錄了軟體中斷!對於其它架構的CPU,有可能在觸發呼叫軟體中斷前,也就是還在處理硬體中斷的時候,就已經開啟了硬體中斷,可能會發生中斷巢狀,在中斷巢狀中是不允許呼叫軟體中斷處理的。Why?我的理解是,在發生中斷巢狀的時候,表明這個時候是系統突發繁忙的時候,核心第一要務就是趕緊把中斷中的事情處理完成,退出中斷巢狀。避免多次巢狀,哪裡有時間處理軟體中斷,所以把軟體中斷推遲到了所有中斷處理完成的時候才能觸發軟體中斷。
3. 軟體中斷的處理過程之前我已經說到,軟中斷的一個很大的目的就是避免中斷處理中,處理的操作過多而丟失中斷。同時中斷還需要考慮到一件事情就是中斷處理過程過長就會影響系統響應時間。如果一箇中斷處理一秒鐘,那你一定能感受到串列埠卡住的現象。從另外一方面說呢,我們又必須考慮中斷處理的操作一定的優先度,畢竟是硬體觸發的事務,關係到網路、塊裝置的效率問題。Linux核心就中斷方面就必須考慮平衡這三個方面的問題。而下面我要分析的__do_softirq函式就恰似在這三者之間打太極,遊刃有餘,面面俱到!
/*
* We restart softirq processing MAX_SOFTIRQ_RESTART times,
* and we fall back to softirqd after that.
*
* This number has been established via experimentation.
* The two things to balance is latency against fairness -
* we want to handle softirqs as soon as possible, but they
* should not be able to lock up the box.
*/
#define MAX_SOFTIRQ_RESTART 10
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));
trace_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();
h->action(h);
if (unlikely(prev_count != preempt_count()))
{
printk(KERN_ERR "huh, entered softirq %td %p"
"with preempt_count %08x,"
" exited with %08x?\n", h - softirq_vec,
h->action, prev_count, preempt_count());
preempt_count() = prev_count;
}
rcu_bh_qsctr_inc(cpu);
}
h++;
pending >>= 1;
}
while (pending);
local_irq_disable();
pending = local_softirq_pending();
if (pending && --max_restart)
goto restart;
if (pending)
wakeup_softirqd();
trace_softirq_exit();
account_system_vtime(current);
_local_bh_enable();
}
__do_softirq函式處理軟體中斷過程如下圖流程分析
4. 首先呼叫local_softirq_pending函式取得目前有哪些位存在軟體中斷
5. 呼叫__local_bh_disable關閉軟中斷,其實就是設定正在處理軟體中斷標記,在同一個CPU上使得不能重入__do_softirq函式
6. 重新設定軟中斷標記為0,set_softirq_pending重新設定軟中斷標記為0,這樣在之後重新開啟中斷之後硬體中斷中又可以設定軟體中斷位。
7. 開啟硬體中斷
8. 之後在一個迴圈中,遍歷pending標誌的每一位,如果這一位設定就會呼叫軟體中斷的處理函式。在這個過程中硬體中斷是開啟的,隨時可以打斷軟體中斷。這樣保證硬體中斷不會丟失。
9. 之後關閉硬體中斷,檢視是否又有軟體中斷處於pending狀態,如果是,並且在本次呼叫__do_softirq函式過程中沒有累計重複進入軟體中斷處理的次數超過10次,就可以重新呼叫軟體中斷處理。如果超過了10次,就呼叫wakeup_softirqd();喚醒核心的一個程序來處理軟體中斷。設立10次的限制,也是為了避免影響系統響應時間。
4. 處理軟中斷核心執行緒
之前我說到不能讓CPU長時間來處理中斷事務,這樣會影響系統的響應時間,嚴重影響使用者和系統之間的互動式體驗。所以在之前的__do_softirq中最多將迴圈執行10次,那麼當執行了10次仍然有軟中斷在pending狀態,這個時候應該怎麼處理呢?系統將喚醒一個軟體中斷處理的核心程序,在核心程序中處理pending中的軟體中斷。這裡要注意,之前我們分析的觸發軟體中斷的位置其實是中斷上下文中,而在軟中斷的核心執行緒中實際已經是程序的上下文。
這裡說的軟中斷上下文指的就是系統為每個CPU建立的ksoftirqd程序。
看完這個函式,我不得不佩服這個函式設計的精巧!而我更多的從中體會到其中蘊藏的一種做人的道理。那就是做人要霸道一點,太謙和太恭維不行,但是又不能橫行霸道,原則的問題要公平講理,一定的時候顧及別人的利益,好處不能一個人獨吞。這就跟下面ksoftirqd處理過程一樣,該狠的時候禁止搶佔,其它程序別想排程到哦,但是自己佔用CPU時間過長的話,也自覺的問一問是不是該釋放CPU給其它程序了。
下面我們就來分析一下這個處理過程怎麼就體現了上面的這種說法呢?軟中斷的核心程序中主要有兩個大迴圈,外層的迴圈處理有軟體中斷就處理,沒有軟體中斷就休眠。內層的迴圈處理軟體中斷,並每迴圈一次都試探一次是否過長時間佔據了CPU,需要排程釋放CPU給其它程序。具體的操作在註釋中做了解釋。
static int ksoftirqd(void *__bind_cpu)
{
set_current_state(TASK_INTERRUPTIBLE);
while (!kthread_should_stop())
{
/*不管三七二十一首先禁止搶佔,我掌握CPU,並全憑我自己掌握排程*/
preempt_disable();
if (!local_softirq_pending())
{
preempt_enable_no_resched();
/*如果沒有軟中斷在pending,那就讓出CPU來吧*/
schedule();
/*我被喚醒了,首先掌握CPU,不讓自己被搶佔,自己決定自己的是否要排程*/
preempt_disable();
}
__set_current_state(TASK_RUNNING);
while (local_softirq_pending())
{
/* Preempt disable stops cpu going offline.
If already offline, we'll be on wrong CPU:
don't process */
if (cpu_is_offline((long)__bind_cpu))
goto wait_to_die;
/*處理軟中斷*/
do_softirq();
/*雖然我自己掌握是否要排程,雖然我可以一直不排程,但是我是
個正直的人,執行一段時間後我會看看是否需要排程,還其它程序執行*/
preempt_enable_no_resched();
cond_resched();
preempt_disable();
rcu_qsctr_inc((long)__bind_cpu);
}
preempt_enable();
set_current_state(TASK_INTERRUPTIBLE);
}
__set_current_state(TASK_RUNNING);
return 0;
wait_to_die:
preempt_enable();
/* Wait for kthread_stop */
set_current_state(TASK_INTERRUPTIBLE);
while (!kthread_should_stop())
{
schedule();
set_current_state(TASK_INTERRUPTIBLE);
}
__set_current_state(TASK_RUNNING);
return 0;
}