什么情況下會發生搶占呢？最常見的現象就是一個進程執行時間太長了，是時候切換到另一個進程了。
那怎么衡量一個進程的運行時間呢？在計算機里面有一個時鍾，會過一段時間觸發一次時鍾中斷，通知操作系統，時間又過去一個時鍾周期，這是個很好的方式，可以查看是否是需要搶占的時間點。
時鍾中斷處理函數會調用 scheduler_tick()。
void scheduler_tick(void) { int cpu = smp_processor_id(); // 1. 取出當前 CPU 的運行隊列 struct rq *rq = cpu_rq(cpu); // 2. 得到這個隊列上當前正在運行中的進程的 task_struct struct task_struct *curr = rq->curr; ...... // 3. 調用這個 task_struct 的調度類的 task_tick 函數，來處理時鍾事件 curr->sched_class->task_tick(rq, curr, 0); cpu_load_update_active(rq); calc_global_load_tick(rq); ...... } // 如果當前運行的進程是普通進程，調度類為 fair_sched_class，調用的處理時鍾的函數為 task_tick_fair static void task_tick_fair(struct rq *rq, struct task_struct *curr, int queued) { // 根據當前進程的 task_struct，找到對應的調度實體 sched_entity 和 cfs_rq 隊列，調用 entity_tick struct cfs_rq *cfs_rq; struct sched_entity *se = &curr->se; for_each_sched_entity(se) { cfs_rq = cfs_rq_of(se); entity_tick(cfs_rq, se, queued); } ...... } static void entity_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr, int queued) { // 更新當前進程的 vruntime update_curr(cfs_rq); update_load_avg(curr, UPDATE_TG); update_cfs_shares(curr); ..... if (cfs_rq->nr_running > 1) // 檢查是否是時候被搶占了 check_preempt_tick(cfs_rq, curr); } static void check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr) { unsigned long ideal_runtime, delta_exec; struct sched_entity *se; s64 delta; // ideal_runtime 是一個調度周期中，該進程運行的理想時間 ideal_runtime = sched_slice(cfs_rq, curr); // sum_exec_runtime 指進程總共執行的實際時間; // prev_sum_exec_runtime 指上次該進程被調度時已經占用的實際時間。 delta_exec = curr->sum_exec_runtime - curr->prev_sum_exec_runtime; // delta_exec 這次調度占用實際時間，如果大於 ideal_runtime，則應該被搶占了 if (delta_exec > ideal_runtime) { resched_curr(rq_of(cfs_rq)); return; } ...... // 取出紅黑樹中最小的進程 se = __pick_first_entity(cfs_rq); // 如果當前進程的 vruntime 大於紅黑樹中最小的進程的 vruntime，且差值大於 ideal_runtime，也應該被搶占了 delta = curr->vruntime - se->vruntime; if (delta < 0) return; if (delta > ideal_runtime) resched_curr(rq_of(cfs_rq)); }
當發現當前進程應該被搶占，不能直接把它踢下來，而是把它標記為應該被搶占。
為什么呢？一定要等待正在運行的進程調用 __schedule 才行啊，所以這里只能先標記一下。
標記一個進程應該被搶占，都是調用 resched_curr，它會調用 set_tsk_need_resched，標記進程應該被搶占，但是此時此刻，並不真的搶占，而是打上一個標簽 TIF_NEED_RESCHED。
static inline void set_tsk_need_resched(struct task_struct *tsk) { set_tsk_thread_flag(tsk,TIF_NEED_RESCHED); }
另外一個可能搶占的場景是當一個進程被喚醒的時候。
當一個進程在等待一個 I/O 的時候，會主動放棄 CPU。但是當 I/O 到來的時候，進程往往會被喚醒。
這個時候是一個時機。當被喚醒的進程優先級高於 CPU 上的當前進程，就會觸發搶占。
try_to_wake_up() 調用 ttwu_queue 將這個喚醒的任務添加到隊列當中。
ttwu_queue 再調用 ttwu_do_activate 激活這個任務。
ttwu_do_activate 調用 ttwu_do_wakeup。
這里面調用了 check_preempt_curr 檢查是否應該發生搶占。
如果應該發生搶占，也不是直接踢走當前進程，而是將當前進程標記為應該被搶占。
static void ttwu_do_wakeup(struct rq *rq, struct task_struct *p, int wake_flags, struct rq_flags *rf) { check_preempt_curr(rq, p, wake_flags); p->state = TASK_RUNNING; trace_sched_wakeup(p); ...... }
到這里，搶占問題只做完了一半。就是標識當前運行中的進程應該被搶占了，但是真正的搶占動作並沒有發生。
搶占的時機
真正的搶占需要時機，也就是需要那么一個時刻，讓正在運行中的進程有機會調用一下 __schedule。
這個時機分為用戶態和內核態。
對於用戶態的進程來講，從系統調用中返回的那個時刻，是一個被搶占的時機。
64 位的系統調用的鏈路為：
do_syscall_64->syscall_return_slowpath->prepare_exit_to_usermode->exit_to_usermode_loop
static void exit_to_usermode_loop(struct pt_regs *regs, u32 cached_flags) { while (true) { /* We have work to do. */ local_irq_enable(); if (cached_flags & _TIF_NEED_RESCHED) schedule(); ...... } }
對於用戶態的進程來講，從中斷中返回的那個時刻，也是一個被搶占的時機。
在 arch/x86/entry/entry_64.S 中有中斷的處理過程。
common_interrupt: ASM_CLAC addq $-0x80, (%rsp) interrupt do_IRQ ret_from_intr: popq %rsp testb $3, CS(%rsp) jz retint_kernel /* Interrupt came from user space */ GLOBAL(retint_user) mov %rsp,%rdi call prepare_exit_to_usermode TRACE_IRQS_IRETQ SWAPGS jmp restore_regs_and_iret /* Returning to kernel space */ retint_kernel: #ifdef CONFIG_PREEMPT bt $9, EFLAGS(%rsp) jnc 1f 0: cmpl $0, PER_CPU_VAR(__preempt_count) jnz 1f call preempt_schedule_irq jmp 0b
中斷處理調用的是 do_IRQ 函數，中斷完畢后分為兩種情況，一個是返回用戶態，一個是返回內核態。
先來看返回用戶態這一部分，retint_user 會調用 prepare_exit_to_usermode，最終調用 exit_to_usermode_loop，和上面的邏輯一樣，發現有標記則調用 schedule()。
對內核態的執行中，被搶占的時機一般發生在 preempt_enable() 中。
在內核態的執行中，有的操作是不能被中斷的，所以在進行這些操作之前，總是先調用 preempt_disable() 關閉搶占，當再次打開的時候，就是一次內核態代碼被搶占的機會。
preempt_enable() 會調用 preempt_count_dec_and_test()，判斷 preempt_count 和 TIF_NEED_RESCHED 是否可以被搶占。
如果可以，就調用 preempt_schedule->preempt_schedule_common->__schedule 進行調度。
#define preempt_enable() \ do { \ if (unlikely(preempt_count_dec_and_test())) \ __preempt_schedule(); \ } while (0) #define preempt_count_dec_and_test() \ ({ preempt_count_sub(1); should_resched(0); }) static __always_inline bool should_resched(int preempt_offset) { return unlikely(preempt_count() == preempt_offset && tif_need_resched()); } #define tif_need_resched() test_thread_flag(TIF_NEED_RESCHED) static void __sched notrace preempt_schedule_common(void) { do { ...... __schedule(true); ...... } while (need_resched())
在內核態也會遇到中斷的情況，當中斷返回的時候，返回的仍然是內核態。
這個時候也是一個執行搶占的時機，在上面中斷返回的代碼中返回內核的那部分代碼，調用的是 preempt_schedule_irq。
asmlinkage __visible void __sched preempt_schedule_irq(void) { ...... do { preempt_disable(); local_irq_enable(); __schedule(true); local_irq_disable(); sched_preempt_enable_no_resched(); } while (need_resched()); ...... }