檢查點:
A) 返回用戶空間/返回內核空間:
----2.4 :只在返回user space的時候纔會檢查任務是否需要被調度.
----2.6:除了保留這個檢查點,新增了返回內核空間的檢查點, 這個檢查點調用preempt_schedule_irq,這就是搶佔式調度. 2.6中調用__schedule前有個關鍵的操作, add_preempt_count(PREEMPT_ACTIVE),這標誌這此schedule是搶佔式調度,__schedule 通過PREEMPT_ACTIVE這個標誌知道這是一次搶佔. 返回內核空間的時候只有peeempt_count==0才能夠搶佔當前進程. 2.6在返回用戶空間的時候檢查兩個標誌:TIF_NEED_RESCHED和新增的TIF_NEED_RESCHED_DELAYED, 而返回內核空間只檢查TIF_NEED_RESCHED.
B)內核中的其他檢查點
這些剩餘的檢查點分散在diver/mm和fs的一些地方, 這些檢查點,能夠提高內核的響應速度,這種加查點加速了對當前需要調度的進程的調度速度,而不是隻有在返回user space/kernel space的時候才檢查.
----2.4: 比較單純,就是檢查current->need_resched (TASK_NEED_RESCHED),然後調用schedule.
----2.6: 有兩種檢查點,TIF_NEED_RESCHED和新增的TIF_NEED_RESCHED_DELAYED.主要區別在A)中已有敘述.另一而主要區別是2.6中擴展了很多搶佔式的檢查點.
TIF_NEED_RESCHED:返回user space和返回kernel space都要檢查.need_resched()也只檢查這個標誌. 而這個標記實現的檢查點又有兩種途徑:
a)通過preempt_check_resched 實現的檢查點,進行的是搶佔式調度. 然後直接調用,和通過unlock spin,bh,rwlock這些函數廣泛分佈到內核各個地方.
b)通過need_resched()實現的檢查點: 這個途徑實現的檢查點一部分是非搶佔式調度,另一部分是搶佔式調度通,搶佔式的檢查點都是調用的cond_resched實現的(下面再詳細分析這個函數).直接通過need_resched()來調用schedule和cond_resched的地方不是特別多.
c)直接在一些路徑調用cond_resched實現的搶佔式檢查點.
TIF_NEED_RESCHED_DELAYED: 這個是RT linux patches set進行的擴展, 對應一個need_resched_delayed,然而幾乎沒有通過這個檢查函數實現的檢查點. 而preempt_check_resched_delayed()通過被wait queue的__wake_up和complete間接的被廣泛應用.
trigger :對應檢查點,必須有地方trigger上述的檢查點.
---- 2.4.18
2.4中trigger比較有限. 最重要的是時鐘中斷的update_process_times, 監視p->counter,等進程消耗完時間片就觸發對這個進程的一次調度,其次就是 __schedule_tail->reschedule_idle 在每次調度完成之後試圖給prev找到一個合適的CPU去運行, 通過IPI觸發另外一個cpu重新調度. 還有就是較少運行的sys_sched_yield,setscheduler.
----2.6.25.4-rt3
TIF_NEED_RESCHED :
設置這個標誌的函數主要有兩個: resched_task(),set_tsk_need_resched().主要是resched_task,而resched_task的調用者 check_preempt_curr更是通過:try_to_wake_up/wake_up_new_task/pull_task /__migrate_task 這些被廣泛使用的函數, 從而分佈在內核中大量的檢查點有機會搶佔進程.
對應2.4, 最典型的trigger點是hrtick()->curr->sched_class->task_tick->..->set_tsk_need_resched.
TIF_NEED_RESCHED_DELAYED:
對應這個檢查點的trigger幾乎沒有. 看來要fade out了.
直接調用schedule:
區別不大.
cond_resched:這個函數在內核實現喝多檢查點:
當前進程需要被搶佔,且不是處PREEMPT_ACTIVE的環境下,即防止schedule() -> reacquire_kernel_lock() -> down() -> might_sleep()->cond_resched這個循環