乙個程序被喚醒，在linux中是呼叫try_to_wake_up函式，對於rt程序也不例外，對於一般程序而言，如果在乙個cpu執行佇列上被喚醒的程序的優先順序大於該cpu的當前程序，那麼就會發生搶占，而如果兩個程序都是rt程序則不會發生搶占，理由是cache的保持，如果發生搶占的話，被搶占的rt程序將丟失其所有的cache，可是這樣做合理嗎？
先看一下rt程序的特徵，這種程序一旦執行，除非自願放棄cpu，一般是不會停止執行的，對於高優先順序的rt程序總是優先執行，如果對於rt程序為了保持cache不搶占的話，除了cache的保持之外，其實是得不到任何優勢的，並且，在這種情況下還會造成rt程序的桌球效應，也就是造成rt程序頻繁遷移，在很多rt程序爭搶乙個資源，比如lock的情況下，這種桌球效應帶來的弊端更加明顯，低優先順序的rt程序釋放了lock，喚醒了高優先順序的rt程序，由於此時當前cpu上的程序仍然是低優先順序的程序，所有被喚醒的高優先順序程序不得不被遷移到別的cpu上執行，如果低優先順序的程序沒有釋放資源，而由於另乙個原因睡眠了，此時它的優先順序可能已被提公升，當它再度被另一rt程序喚醒的時候，即使它擁有高優先順序也不得不遷移到另外的cpu上，這些遷移動作肯定會影響效能的。可以說，rt程序排程的無條件不搶占特性大大削弱了高優先順序rt程序的優勢，高優先順序rt程序除了在執行佇列的位置靠前之外，沒有多少優勢可言了。
確實，如果是由於非爭搶資源被釋放原因的喚醒，那搶占正在執行的rt程序確實對於cache優化是一種抵消，然而要知道即使這樣我們也只是損失了相對低優先順序rt程序的效能，我們得到的是避免了一次高優先順序rt程序的遷移。另一方面，當我們面對多個rt程序爭搶資源這種型別的睡眠/喚醒時，搶占的優勢就明顯了，有時乙個又有很高優先順序的rt程序在執行中由於得不到資源而睡眠，這種睡眠時間一般不會太久，只是一小會兒，它爭搶的資源此時正在被乙個低優先順序的rt程序佔據，此時它提公升低優先順序程序的優先順序，以使它不被搶占地盡快完成資源的釋放，這一切都是為了高優先順序程序不會睡得太久，於是資源盡可能早的被釋放了，高優先順序程序被喚醒，此時應該知道，將此高優先順序rt程序喚醒在它本來執行的cpu上是乙個最佳的選擇。
這就是乙個權衡的問題了，是保留cache還是最小化遷移，還是交給排程器吧，嚴格按照優先順序排程會好一些，起碼能照顧高優先順序的rt程序，使得高優先順序的rt程序的優勢更加明顯。於是，新的2.6.37核心對此進行了改進，補丁很簡單：
--- a/kernel/sched_rt.c
+++ b/kernel/sched_rt.c
@@ -960,18 +960,18 @@ select_task_rq_rt(struct rq *rq, struct task_struct *p, int sd_flag, int flags)
if (unlikely(rt_task(rq->curr)) &&
+ rq->curr->prio < p->prio &&
(p->rt.nr_cpus_allowed > 1))
搶占程序排程的原則
1 時間片原則 各程序按系統分配給的乙個時間片執行，當該時間片用完或由於該程序等待某事件發生而被阻塞時，系統就停止該程序的執行而重新進行排程。2 優先順序原則 每個程序均賦於乙個排程優先順序，通常一些重要和緊急的程序賦於較高的優先順序。當乙個新的緊迫程序到達時，或者乙個優先順序高的程序從阻塞狀態變成...
實時作業系統的任務排程示例之搶占
什麼是任務搶占？實時作業系統大多都是基於優先順序排程的搶占式的核心，這句話每本關於rtos的資料都有。樓主最怕這種每個字都認識，但連到一起就很不好理解的書面語言。直白點說，就是 1 每個任務都有自己的優先順序，一般都是在create task的時候以函式入參的形式確定，有的rtos也提供api允許應...
對待問題的正確態度
如果在排錯開始前,除錯著已經存在畏懼心理,那麼是不可能找到問題真相的.下面的幾點可以幫助除錯者克服這樣的畏懼情緒.屢試不爽的方法 無論多麼複雜的程式,總可以被簡化.我們可以先把程式的功能砍掉一半,看看問題是否會發生,以此來縮小問題的範圍.重複使用這樣的二分法,總可以把程式簡化到只剩一行 因此,無論什...