1樓：Suede Young
排程器分為週期性排程器和主排程器。週期性排程器由週期性時鐘中斷觸發，負責對run queue中的各個程序計算時間（其實是負荷權重吧），run queue是由rbtree排列的，優先順序最高的排在樹的左下節點，等待執行schedule（）（也就是主排程器）時被呼叫。
觸發schedule（）的時機實際上只有兩個：第一種是系統呼叫或者中斷返回時，根據TIF_NEED_RESCHED標誌決定是否呼叫schedule()函式（從效率方面考慮，趁著還在核心態把該處理的事情處理完畢）；第二種情況是當前任務因為原因需要睡眠，程序睡眠後立即呼叫schedule()函式，在核心中這種情況也比較多，比如磁碟、網絡卡等裝置驅動程式中。（詳解Linux核心程序排程函式schedule()的觸發和執行時機_Linux_指令碼之家）
時鐘中斷會觸發中斷返回，因此每次時鐘中斷都會觸發schedule（），但是只有當current task 被設定了TIF_NEED_RESCHED標誌，才會呼叫具體的cfs或者rt排程器類執行排程。通常情況下，乙個process執行4ms左右。
2樓：Bean Lee
我能想到兩個時機，第乙個是時鐘中斷。
task_handle_peroidic --->tick_periodic--->update_process_times--->scheduler_tick--->task_tick
程序排程採用了模組化的方法，每一種排程演算法，都要實現自己的task_tick函式，對於CFS排程類，該函式的例項是task_tick_fair。在該演算法中，會判斷是否需要搶占當前程序。這個是否搶占，委託給了check_preempt_tick函式負責。
你說的程序的時間片耗盡，就是這個時鐘中斷trigger的。
/*如果當前程序實際執行時間超過了應該執行的時間，則需要排程出去，被搶占*/
if (delta_exec > ideal_runtime) {
/*resched_task 會負責設定need_resched標誌位*/
resched_task(rq_of(cfs_rq)->curr);
clear_buddies(cfs_rq, curr);
return;
/* 如果當前程序執行時間低於排程最小粒度，不允許發生搶占 */
if (delta_exec < sysctl_sched_min_granularity)
return;
另外乙個時機是喚醒搶占。
當新程序建立出來之後，
do_fork--->wake_up_new_task--->check_preempt_curr
當程序從等待佇列醒來時
try_to_wake_up--->ttwu_queue--->ttwu_do_activate--->ttwu_do_wakeup--->check_preempt_curr
這條路都會走到check_preempt_curr用來判斷醒來程序是否應該搶占當前程序。
第二個問題，應該是和等待佇列有關，可以重點看看等待佇列和try_to_wake_up函式。
3樓：貳號仙菜小紅
關於第乙個問題，我是這樣理解的：
時間中斷是一種硬體的電氣特性（例如微控制器裡面什麼晶體振盪之類，我也不是很懂），每隔固定的時間週期，時間中斷器就會向cpu傳送乙個中斷訊號。於是每當cpu檢測到時間中斷，那麼它必定是經過了某個固定timeslice。
再補充乙個更加詳細的例子，附有原始碼分析
時鐘中斷是rt-thread的執行緒排程器的驅動力
Python 的程序管理器？
朽木雕花 你這也不是程序管理器啊，你需要的呼叫nodejs的函式來解決問題。一般這個還分平台，如果是unix的話一般是exec函式族，如果是windows的話另有一套函式。不過這些事底層函式，直接用的話比較複雜，因為需要處理一堆錯誤和訊號處理之類的事情。如果是python呼叫別的程序直接用subpr...
如何判斷程序上下文切換對效能的影響？
鄒同學 vmstat看看in和cs，如果cs比較大，且比in大。磁碟io使用又不高，機器負載卻比較高。那可能上下文切換影響效能了 東籬 zhihu 支援 Markdown 語法嘛，搞得這些字都不能在 vim 裡面碼.這麼來說吧，在 Linux 中 不懂 Windows 你大概可以通過 proc 看出...
能從路由器和TCP程序的工作方式的角度，解釋一下IP TCP資料報首部格式各欄位出現順序的合理性嗎？
徐方鑫 tlv結構，這個你在ip和tcp裡面感覺實際不明顯。這個實際上是和定長header和動長的header有關，一般動長的頭部首先是type，知道乙個識別幀的大致格式，當然這個格式是有可變的地方，可以當做是乙個範本，然後是length，把頭部的長度隔離出來，也就是抽取出整個頭部，然後再乙個個ve...