在這個函數中有如下幾行：
cmpl $0, _need_resched
jne reschedule
……
restore_all:
RESTORE_ALL
reschedule:
call SYMBOL_NAME(schedule)
jmp ret_from_sys_call
這幾行的意思很明顯：檢測 need_resched 標志，如果此標志為非0，那麼就轉到reschedule處調用調度程序schedule（）進行進程的選擇。調度程序schedule（）會根據具體的標准在運行隊列中選擇下一個應該運行的進程。當從調度程序返回時，如果發現又有調度標志被設置，則又調用調度程序，直到調度標志為0，這時，從調度程序返回時由RESTORE_ALL恢復被選定進程的環境，返回到被選定進程的用戶空間，使之得到運行。
以上就是時鐘中斷這個最頻繁的調度時機。討論這個的主要目的是為了對時機4有個大致的了解。
最後要說明的是，系統調用返回函數ret_from_sys_call（）是從系統調用、異常及中斷返回函數通常要調用的函數，但並不是非得調用，對於那些要經常被響應的和要被盡快處理的中斷請求信號，為了減少系統開銷，處理完成後並不調用 ret_from_sys_call（）（因為很顯然的，從這些中斷處理程序返回到的用戶空間肯定是那個被中斷的進程，無需重新選擇），並且，它們作的工作要盡可能少，因為響應的頻率太高了。
Linux 調度程序和其他的UNIX調度程序不同，尤其是在“nice level”優先級的處理上，與優先權調度（priority高的進程最先運行）不同，Linux用的是時間片輪轉調度（Round Robing），但同時又保證了高優先級的進程運行的既快、時間又長（both sooner and longer）。而標准的UNIX調度程序都用到了多級進程隊列。大多數的實現都用到了二級優先隊列：一個標准隊列和一個實時（“real time”）隊列。一般情況下，如果實時隊列中的進程未被阻塞，它們都要在標准隊列中的進程之前被執行，並且，每個隊列中，“nice level”高的進程先被執行。
總體上，Linux 調度序程在交互性方面表現很出色，當然了，這是以犧牲一部分“吞吐量”為代價的。
