我吃西红柿,欢乐颂小说结局是什么,已完本玄幻小说排行榜

在當今數字時代，手機已成為人們日常生活中不可或缺，多任務處理和實時響應對于用戶體驗越來越重要，搶占(preemption)機制在提升系統性能和用戶體驗方面發揮了至關重要的作用。內核搶占機制使得系統能夠有效地管理多任務處理，確保系統對用戶操作的快速響應，并在資源緊張的情況下仍能保持穩定和流暢的運行。

本篇文檔旨在詳細探討Linux內核中的搶占機制，涵蓋其基本概念、實現細節、性能影響以及相關的調試方法。通過對搶占機制的深入解析，我們希望能夠幫助讀者更好地理解和優化Linux系統的性能，并在實際工作應用這些知識。

為了使內容組織更清晰，本文檔將使用Linux6.1內核，按照以下結構展開：

1.基本概念：首先講解系統中的latency是如何產生的，為什么會產生

2.內核搶占的實現機制：從latency的角度說明了為什么需要搶占，什么是搶占，內核的搶占模型是怎么樣的，內核中搶占點的設置、搶占計數的機制，以及如何在內核代碼中控制搶占

3.Linux內核中的搶占實現：什么是內核搶占和實現方式，包括在什么情況下會發生搶占以及搶占的觸發條件

4.實例分析：通過實際案例中一個高優先級的線程長時間搶占不到資源，來看如何定位類似問題

1. latency in linux

內核搶占允許高優先級任務中斷正在執行的低優先級任務，從而減少調度延遲，提高系統響應性，那么我們就需要知道對于Linux內核中有哪些因素會導致響應不及時。首先，我們來看看典型應用場景如下：

一個硬件中斷發生，并通過喚醒一個更高優先級的任務，一段時間后，高優先級的任務才得以執行，那么latency是實時響應關注的重點。

接下來細化該過程，初始狀態時，進程處于睡眠等待，中斷發生，到喚醒這個進程，等待選核選到這個任務，最后發生上下文切換，直到該進程運行，這個時間經歷了以下幾個完整的完成，這個統稱為一次Scheduling latency。

這一次的內核調度延遲 = 中斷延遲(interrupt latency) + 處理程序持續時間(handler duration) + 調度程序延遲(scheduler latency) + 調度程序持續時間(scheduler duration)，每一個過程都會影響這個高優先級任務的實時響應。

1.1 中斷延遲

在T0時刻，外設中斷發生，從中斷發生到linux內核響應這個中斷，之間有一個延時，稱為中斷延時，中斷延遲的來源主要有以下原因：

1. 內核中大量使用了并發預防機制之一就是自旋鎖，并且這個是一個common的接口供所有的模塊使用，所以主要的來源就是中斷在內核中被disable，如spinlock_irq()和spinlock_irq_irqsave()，此時當中斷發生時候，內核處于關中斷狀態。

2. 中斷控制器的調度延遲，現代的中斷控制器支持中斷優先級調度，當多個中斷同時發生時，內核會通過比較中斷的優先級來決定處理的順序。較高優先級的中斷會被優先處理，以保證對緊急事件的及時響應。因此，它可能會被高優先級中斷

3. 中斷處理會切換模式，保存寄存器狀態等，這個時間很短

4. Shared Interrupt Line：當多個設備共享同一個中斷時，中斷控制器需要識別和區分不同的中斷源，這個能有效地減少系統中斷線的數量，節省硬件成本。然而，它也帶來了一些潛在的問題，其中之一就是中斷延遲的增加

1.2 中斷處理程序持續時間

在T1時刻，CPU響應了這個中斷，在Linux內核的中斷處理分為上半部和下半部

1. 上半部分，它在禁用中斷的情況下運行，并且應該盡快完成

2. 由上半部分調度的下半部分，在所有待處理的上半部分完成執行后開始，下半部分是開中斷情況下執行，可能被其他中斷打斷

如下圖，在處理完中斷A上部分后，其他外設中斷發生，CPU轉而處理其他中斷，這樣延遲處理中斷A下半部，我們把開始響應中斷到這個處理的時間稱為中斷處理延遲，其處理的整個過程如下圖所示 ? ?

對于前面兩個過程，我們在編寫外設驅動的時候，要特別注意，里面設計大量的關中斷和關搶占的過程，特別我們在一些自旋鎖以及變體的接口，使用不當會導致響應不及時，例如中斷響應不及時，高優先級任務遲遲得不到調度，給用戶的直接感受就是卡頓。

1.3 調度延遲

在T2時刻，中斷處理完后，喚醒了進程。從喚醒進程到進程被調度器選中的這段延時稱為調度延時。

其產生調度延時的主要原因如下：

調度器選中進程A的時間也是不確定的，可能就緒隊列中有比進程A優先級更高的進程

對于這個，就需要了解搶占，盡快的通過搶占來完成任務的切換工作。對于Linux內核是一個支持搶占式操作系統，當一個任務運行在用戶空間并被中斷打斷時，如果中斷處理程序喚醒另外一個任務，我們從中斷處理返回后可以立即調度該任務。對于不同內核支持不同的搶占方式，處理方式也會不同，這個后面會詳細介紹，這里只是作為一個引子，目前存在以下情況會影響調度延遲

當中斷發生時，linux內核正在自旋鎖臨界區里執行，這樣，中斷完成后，不能馬上搶占調度，必須等待linux內核執行完自旋鎖臨界區才能搶占調度，這也會導致延遲的增加，并且很難被發現如下圖所示

1.4 調度持續時間

在T3時刻，調度器選中了進程A，還需要進行上下文切換后才能執行進程A，上下文切換也是具有一定的延時性

? ?

除了前面詳細講解的關鍵路徑之外，Linux的其他非確定性機制也會影響實時任務的執行時間，例如linux是一個基于虛擬內存，由MMU提供，因此內存是按需分配的。每當應用程序首次訪問代碼和數據時，它都是按需加載的，這也會導致巨大的延時，同時C庫服務和內核服務在設計的時候并未考慮實時約束。

1.5優先級倒置

內核搶占是指操作系統內核能夠在某些情況下搶占正在運行的任務并切換到更高優先級的任務。但是在實際的場景中，可能會存在優先級翻轉的問題導致系統響應下降。

例如，低優先級的進程可能持有高優先級所需要的鎖，從而有效地降低該進程的優先級，如果中等優先級進程使用CPU，情況可能會更糟。在簡單的情況下，只要低優先級任務（任務 L）持有鎖，高優先級任務（任務 H）就會被阻塞。這被稱為“有界優先級反轉”，因為反轉的時間長度受低優先級任務在臨界區（持有鎖）中的時間長度的限制。

當中等優先級任務（任務 M）在持有鎖時中斷任務 L 時，會發生無限優先級反轉。之所以稱為“無界”，是因為任務 M 現在可以有效地阻止任務 H 任意時間，因為任務 M 正在搶占任務 L（它仍然持有鎖）。下面簡化了這種危險的事件序列，其過程如下：

低優先級任務L和高優先級的任務H共享資源，在任務L獲取資源后不久，任務H就開始運行。但是任務H必須等待任務L完成資源，因此它被掛起

在任務L完成資源之前，任務M準備好運行，搶占任務L，當任務M（可能還有其他中等優先級的任務）運行時，系統中的最高優先級任務H仍然處于掛起狀態。

2. 為什么需要內核搶占

當一個以優先級為主的調度器中，當一個新的進程(下圖中的task2)進入到可執行(running)的狀態，核心的調度器會檢查它的優先級，若該進程的優先權比目前正在執行的進程(下圖中的task1)還高，核心調度器便會觸發搶占(preempt)，使得正在執行的進程被打斷，而擁有更高優先級的進程會開始執行。

? ?

在不支持內核搶占模型中，搶占點比較少，對于內核搶占，如右圖會在系統中添加很多搶占點，同時會導致執行時間會比左圖多一點，可搶占會導致每隔一定時間去檢查是否需要搶占，這樣也會影響cache,pipeline，這樣就會犧牲吞吐量。從上面圖可以看出，操作系統演進過程中，不是新的就一定比舊的好，需要考量場景選擇合適的方案。從這張圖我們可以看出，內核搶占主要解決以下問題：

提高系統響應實時性和用戶體驗：在不支持內核搶占式內核中，低優先級任務可能會長時間占用CPU，導致高優先級任務無法及時得到處理，主要解決的是latency問題。這種情況會顯著影響系統的響應速度，特別是在實時應用中，可能導致嚴重的性能問題。對于手機場景中，當用戶在使用應用程序時，內核搶占可以確保用戶界面關鍵線程得到足夠的CPU時間，避免界面卡頓和延遲。

避免優先級翻轉：內核搶占結合優先級繼承（Priority Inheritance）等機制，可以有效緩解優先級翻轉問題。當低優先級任務持有高優先級任務需要的資源時，內核搶占機制可以提高低優先級任務的優先級，使其盡快釋放資源，從而減少高優先級任務的等待時間。在Linux中，從2.6開始，rtmutex支持優先級繼承，解決優先級翻轉的問題。

所以需要內核搶占的根本原因就是系統在吞吐量和及時響應之間進行權衡的結果，對于Linux作為一個通用的操作系統，其最初設計就是為了throughput而非確定性時延而設計。但是越來越多的場景對及時響應的要求越來越高，讓更高優先級的任務和關鍵的任務及時得到調度，特別對于我們手機這種交互式的場景中。

3.搶占模型

將搶占視為減少調度程序延遲的一種方法可能很有用，但減少延遲通常也會影響吞吐量，因此需要在完成大量工作（高吞吐量）和在任務準備好運行時立即調度任務（低延遲）之間保持平衡。Linux 內核支持多種搶占模型，以便您可以根據工作負載調整搶占行為。為了讓用戶根據自己的需求進行配置，Linux 提供了 3 種 Preemption Model：

CONFIG_PREEMPT_NONE=y：不允許內核搶占，吞吐量最大的 Model，一般用于 Server 系統，其特點如下(紅色:non-preemptible，綠色:preemptible)：

該模式下只支持用戶搶占，系統調用返回和中斷是唯一的搶占點

CONFIG_PREEMPT_VOLUNTARY=y：內核核心系統的開發者開始著手做低延遲優化，其中一個優化點就是如果有高優先級進程需要處理器，內核代碼也可以被搶占。在一些耗時較長的內核代碼中主動調用cond_resched()讓出CPU，對吞吐量有輕微影響，但是系統響應會稍微快一些。主動搶占（voluntary preemption）功能，它為內核增加了一個受限的內核搶占模式，并且一直使用到現在。

通過向運行在內核模式下的幾個代碼添加顯式搶占點，目前內核中有近千個搶占點，檢查是否經常需要重新調度，并且通過增加必須使用搶占的頻率，減少搶占延遲。

CONFIG_PREEMPT=y：除了處于持有 spinlock 時的 critical section，其他時候都允許內核搶占，響應速度進一步提升，吞吐量進一步下降，一般用于 Desktop / Embedded 系統，目前Andorid中使用的這個配置項

? ?

正如搶占選項名稱所暗示的那樣，這些設置中的每一項都有適當的用例。服務器搶占可用于吞吐量是最重要的。另一方面，實時搶占應該用在嵌入式系統中，其中絕對吞吐量并不重要，但最大體驗延遲才是關鍵。因此，Linux中不同的搶占級別可以在不同的環境中提供很大的靈活性

另外，還有一個沒有合并進主線內核的 Model: CONFIG_PREEMPT_RT，這個模式幾乎將所有的 spinlock 都換成了 preemptable mutex，只剩下一些極其核心的地方仍然用禁止搶占的 spinlock，所以基本可以認為是隨時可被搶占，這部分不在本文討論的范圍之內。

4. 什么是內核搶占

說起這個搶占，在 Linux 內核的 2.4 時代，除非主動調度schedule，否則通常只允許從 system call 或者 interrupt 返回用戶態的時候發生搶占（即產生中斷前，也在用戶態），這可稱之為 "User Preemption"。對于用戶搶占，只支持程序執行在用戶態空間的時候，才可以被搶占，如果進程在Kernel空間執行（系統調用），是不允許搶占的。其執行過程如下：

如上圖一，假設周期性中斷發生在進程A用戶空間，此時進入到內核空間，在周期性調度器實現函數中設置了進程A的TIF_NEED_RESCHED標記位，則在時鐘中斷處理程序返回用戶空間前夕，將調用schedule()函數執行進程調度

如上圖二，假設周期性中斷發生在進程A在內核空間運行之時，時鐘中斷返回前并不會執行進程調度，因為這時返回的是內核空間，而不是用戶空間。在進程A從內核空間返回用戶空間前的工作中，才會檢測TIF_NEED_RESCHED標記位，置位則執行進程調度

何為內核搶占？簡單地說就是當進程進入內核空間運行時，能否被搶占，被剝奪CPU控制權，執行進程調度，從而運行其它進程。還是以中斷和異常為例，對比其差異

如上圖一，假設周期時鐘中斷發生在進程A用戶空間，此時的處理與不支持內核搶占時相同，在中斷處理程序返回用戶空間前夕的工作中，執行進程調度。

如上圖二，假設周期時鐘中斷發生在進程A在內核空間運行時，在時鐘中斷處理程序返回內核空間前的工作中就可能會執行進程調度（搶占計數需為0）。如果在中斷處理程序返回內核空間前沒有執行進程調度，則在返回用戶空間前執行，與不支持內核搶占時相同。

5.Linux搶占標志位--TIF_NEED_RESCHED

首先，我們從數據結構開始，我們會詳細探討thread_info數據結構和它在Linux搶占中的作用和關系

這個數據結構與搶占的發展歷程也有關系，其提供功能如下：

調度標志位設置：早期的Linux，只需要調用set_tsk_need_resched 給當前任務設置 struct thread_info 的 TIF_NEED_RESCHED 標志，所以就提供了一個thread_info的flags中有一個是TIF_NEED_RESCHED，后面會詳細介紹

搶占計數：為了實現內核搶占，新加入preempt_count，這筆提交請參考arm64: preempt: Provide our own implementation of asm/preempt.h，可以發現它是一個共用體，內核某些路徑使用preempt_count，有的是preempt，為何會使用這么奇怪的定義呢？后面將詳細揭曉答案

內核如何檢查一個進程是否需要被調度呢？早期的Linux，在即將返回用戶空間時，檢查進程是否需要重新調度，如果設置了，就會發生調度，內核主要是在thread_info的flag重設置標識來標記進程是否需要被調度，即重新調度need_resched標識TI_NEED_RESCHED，其主要的接口函數為

當內核的某個路徑設置重新調度標志（如時鐘中斷tick 時），會調用到resched_curr 來設置重新調度標志：可以看到除了設置任務的flags 的TIF_NEED_RESCHED 標志外，還設置了preempt.need_resched 為0

清搶占標志，__schedule 中pick到下一個任務后會清除搶占標志，其代碼實現為：

6. 搶占計數preempt_count

在像Linux這樣的多任務系統中，任何執行線程都不能保證只要它想運行就可以獨占訪問處理器。內核總是有能力(多數情況下)搶占一個正在運行的線程，而選擇一個優先級更高的線程來執行。新線程可能是另一個不同的進程，但也可能是一個硬件中斷，或者其他外部事件。

為了正確協調系統中所有任務能正確運行，內核必須跟蹤當前的執行狀態，包括已經被搶占或可能阻止線程被搶占的各種情況。用來進行這個追蹤記錄的基礎，就是在系統中每個任務里存儲的 preemption counter。這個計數器是通過 preempt_count() 函數來訪問的，它的通用定義是這樣的：

這個 counter 可以用來指示當前線程的狀態、它是否可以被搶占，以及它是否被允許睡眠。要實現這個功能的話，就必須在這個 counter 里面記錄若干種不同狀態，因此這個 preempt_count 也被分成了幾個字段（sub-fields）：

最低位的這個 byte 是用來記錄 preempt_disable()嵌套調用的次數，也就是到目前為止 preemption 被 disable 的次數。

SOFTIRQ：當CPU進入軟中處理程序時，對該位域加1，退出時減1

HARDIRQ：當CPU進入硬件中斷處理函數時，對該位域加1，退出時減1，位域數值表示中斷嵌套層級

NMI：CPU進入不可屏蔽中斷處理函數時，此位置1，退出時清0。

最后，最高位表示內核是否已經決定當前進程需要在后面執行時一有機會就馬上被調度出去，讓給其他任務。

接下來，我們看看內核是如何定義這塊的，其定義在include/linux/preempt.h

其每個bit的定義如下：

這里需要特別注意，preempt_count是允許嵌套的，在進入臨界區，被中斷打斷，軟中斷都會存在preempt_count。下圖展示了preempt_count相關的操作函數

這里要特別注意irq這個，它包含了NMI、IRQ和SOFTIRQ ? ?

下圖是preempt_count相關的條件判斷函數，這個在搶占中會頻繁用到

以下接口函數用于檢測preempt_count成員相應位域值，用于檢測CPU是否處于硬件中斷、軟中斷等處理函數中（include/linux/preempt.h）：

in_irq()：當前CPU是否處于硬件中斷處理程序內，返回HARDIRQ計數值。

in_softirq()：當前CPU是否處于軟中斷處理函數內或禁止軟中斷，返回SOFTIRQ計數值。

in_serving_softirq()：當前CPU是否處于軟中斷處理函數內。

in_nmi()：CPU是否處于不可屏蔽中斷處理程序內，返回NMI計數值。

in_interrupt()：CPU是否處于中斷處理程序內（或禁止軟中斷狀態），包括硬件中斷、軟中斷和不可屏蔽中斷。

只要看一下 preempt_count 的值，內核就可知道當前的情況如何。比如，preempt_count 是非零值，就表示當前線程不能被 scheduler 搶占：要么是 preemption 已經被明確 disable 了，要么是 CPU 當前正在處理某種中斷。

同理，非零值也表示當前線程不能睡眠，因為它此刻在運行的上下文必須要持續執行完成。"reschedule needed" 這個 bit 告訴內核，當前有一個優先級較高的進程應該在第一時間獲得 CPU。必須要在 preempt_count 為非零值的情況下，才會設置這個 bit。否則的話，內核早就可以直接對這個進程進行 prempt 搶占，而不是設置此 bit 并等待。

那么哪些情況下，會操作preempt_count，下面是preempt_count相關操作函數

? ?

對于這些接口以及相關變體，都是內核中通用的接口API，所以系統實時性會受驅動中如何使用這些接口的影響。這里我們來看看經常討論的中斷上下文、進程上下文和atomic上下文的關系，首先我們來看看代碼實現：

所以總結一下，對于內核什么時候不允許搶占，在哪些時機是不可調度的，想要搞清這個問題，首先需要介紹一下linux中的四類區間：

中斷

軟中斷

進程上下文中的spin_lock

進程上下文中的其他區域

上述四類區間中，只有第四類區間支持搶占調度，對于1,2,3也就是atomic上下文。當可以調度的事情發生在前3類區間中，即如果在這3類區間中喚醒了高優先級的可以搶占的task，實際上卻不能搶占，直到這3類區間結束。那么對于4類區間是不是一定能發生搶占呢？

7. preempt_enable

為了支持內核搶占而引入了 preempt_count ，如果為 0，就允許 Kernel Preemption，否則就不允許。內核函數preempt_enable/preempt_disable用來內核代碼臨界區動態關閉和打開內核搶占，詳細的用法請參考preempt-locking。

內核代碼中preempt_disable()和preempt_enable()函數總是成對出現的，用于保證進程在執行這兩個函數之間的代碼時，不會發生進程調度（當前進程不會被搶占，不被搶占不是說不能被中斷，硬件中斷還是允許的，只是中斷還是返回原進程）

preempt_disable()函數用于禁止內核搶占，函數定義如下（include/linux/preempt.h）

這個比較簡單，preempt_count加一，然后做了一個內存屏障，增加搶占計數器以防止重新調度，不管處于哪種搶占模式，都不允許搶占。

內核搶占函數preempt_enable()定義在include/linux/preempt.h頭文件內：

preempt_enable()函數內對搶占計數值減1，如果減1后為0，并且進程TIF_NEED_RESCHED標記置位了，則調用__preempt_schedule()函數執行進程調度（搶占當前進程）。

對于ARM64，使用64位的preempt_count，通過將其劃分為count和need_resched來管理，判斷 preempt_count 和 TIF_NEED_RESCHED 看是否可以被搶占

? ?

這個首先來檢查若當前CPU處于關中斷狀態和preempt_count不為0，就禁止搶占，反之就執行搶占。

內核代碼里面通常直接調用preempt_enable比較少，但是調用鎖的地方比較多，例如常見的spinlock等，目前內核的這種鎖機制又是一個處于泛濫的趨勢，所以可以認為每次調用spinlock結束時默認都會發起一次隱式搶占

8. Linux內核中的搶占實現

在當前進程被搶占的場景下，調度并不是立刻發生，而是延遲執行，具體的方法是設定當前進程的need_resched等于1，然后靜靜的等待最近一個調度點的來臨，當調度點到來的時候，內核會調用schedule函數，搶占當前task的執行。這部分的內容比較多，有興趣的同學可以自行查看源碼，大致梳理了一個相關知識的導圖。