linux進程線程調度

『壹』 linux進程與線程的區別

很多朋友都想知道linux進程與線程的區別？下面就一起來了解一下吧！

linux進程與線程的區別

進程是在某個數據知雹者集合上具有獨立功能的一次運行活動，也是系統進行資源肆檔分配和調度的一個獨立單位。線程在進程方面屬於進程的實體，是CPU調度和分配的基本單位，基本上線程自己沒有擁有任何的系統資源搭薯，只擁有一點在運行中必備的資源（如程序計數器、一組寄存器和棧），但是它可以與同屬一個進程的線程共享資源。

Linux的用處

linux是一套免費開放源代碼的操作系統，用戶可以按照自己的想法來修改源代碼，它的每一個操作，你都能夠充分了解，這對計算機方面的愛好者是有很大幫助的，它可以讓用戶知道系統是怎樣工作的。

Linux的語言

linux開發用的是C語言和匯編語言。C語言是Linux的「母語」，這也是linux這個開源環境和本身機制所導致的。Linux的內核部分基本都是用C語言來編寫的，還有部分是用匯編語言寫的。

本文章基於ThinkpadE15品牌、centos7系統撰寫的。

『貳』 Linux 進程、線程和CPU的關系，cpu親和性

1、物理CPU數：機器主板上實際插入的cpu數量，比如說你的主板上安裝了一塊8核CPU，那麼物理CPU個數就是1個，所以物理CPU個數就是主板上安裝的CPU個數。

2、物理CPU核數：單個物理CPU上面有多個核，物理CPU核數=物理CPU數✖️單個物理CPU的核
3、邏輯CPU核數：一般情況，我們認為一顆CPU可以有多個核，加上intel的超線程技術(HT), 可以在邏輯上再分一倍數量的CPU core出來。邏輯CPU核數=物理CPU數✖️單個物理CPU的核*2
4、超線程技術(Hyper-Threading)：就是利用特殊的硬體指令，把兩個邏輯CPU模擬成兩個物理CPU，實現多核多線程。我們常聽到的雙核四線程/四核八線程指的就是支持超線程技術的CPU。

1、並行：兩件（多件）事情在同一時刻一起發生。
2、並發：兩件（多件）事情在同一時刻只能有一個發生，由於CPU快速切換，從而給人的感覺是同時進行。
3、進程和線程
進程是資源分配的最小單位，一個程序有至少一個進程。線程是程序執行的最小單位。一個進程有至少一個線程。
線程之間的通信更方便，同一進程下的線程共享全局變數、靜態變數等數據，而進程之間的通信需要以通信的方式（IPC)進行。多進程程序更健壯，多線程程序只要有一個線程死掉，整個進程也死掉了，而一個進程死掉並不會對另外一個進程造成影響，因為進程有自己獨立的地址空間。
4、單核多線程：單核CPU上運行多線程， 同一時刻只有一個線程在跑，系統進行線程切換，系統給每個線程分配時間片來執行，看起來就像是同時在跑， 但實際上是每個線程跑一點點就換到其它線程繼續跑。
5、多核多線程：每個核上各自運行線程，同一時刻可以有多個線程同時在跑。

1、對於單核：多線程和多進程的多任務是在單cpu交替執行（時間片輪轉調度，優先順序調度等），屬於並發
2、對於多核：同一個時間多個進程運行在不同的CPU核上，或者是同一個時間多個線程能分布在不同的CPU核上（線程數小於內核數），屬於並行。
3、上下文切換：上下文切換指的是內核（操作系統的核心）在CPU上對進程或者線程進行切換。上下文切換過程中的信息被保存在進程式控制制塊（PCB-Process Control Block）中。PCB又被稱作切換幀（SwitchFrame）。上下文切換的信息會一直被保存在CPU的內存中，直到被再次使用。

CPU 親和性（affinity）就是進程要在某個給定的 CPU 上盡量長時間地運行而不被遷移到其他處理器的傾向性。這樣可以減少上下文切換的次數，提高程序運行性能。可分為：自然親和性和硬親和性
1、自然親和性：就是進程要在指定的 CPU 上盡量長時間地運行而不被遷移到其他處理器，Linux 內核進程調度器天生就具有被稱為 軟 CPU 親和性（affinity） 的特性，這意味著進程通常不會在處理器之間頻繁遷移。這種狀態正是我們希望的，因為進程遷移的頻率小就意味著產生的負載小。Linux調度器預設就支持自然CPU親和性(natural CPU affinity): 調度器會試圖保持進程在相同的CPU上運行。
2、硬親和性：簡單來說就是利用linux內核提供給用戶的API，強行將進程或者線程綁定到某一個指定的cpu核運行。Linux硬親和性指定API：taskset .

taskset [options] mask command [arg]...
taskset [options] -p [mask] pid

taskset 命令用於設置或者獲取一直指定的 PID 對於 CPU 核的運行依賴關系。也可以用 taskset 啟動一個命令，直接設置它的 CPU 核的運行依賴關系。

CPU 核依賴關系是指，命令會被在指定的 CPU 核中運行，而不會再其他 CPU 核中運行的一種調度關系。需要說明的是，在正常情況下，為了系統性能的原因，調度器會盡可能的在一個 CPU 核中維持一個進程的執行。強制指定特殊的 CPU 核依賴關系對於特殊的應用是有意義的
CPU 核的定義採用位定義的方式進行，最低位代表 CPU0，然後依次排序。這種位定義可以超過系統實際的 CPU 總數，並不會存在問題。通過命令獲得的這種 CPU 位標記，只會包含系統實際 CPU 的數目。如果設定的位標記少於系統 CPU 的實際數目，那麼命令會產生一個錯誤。當然這種給定的和獲取的位標記採用 16 進制標識。
0x00000001
代表 #0 CPU
0x00000003
代表 #0 和 #1 CPU
0xFFFFFFFF
代表 #0 到 #31 CPU

-p, --pid
對一個現有的進程進行操作，而不是啟動一個新的進程
-c, --cpu-list
使用 CPU 編號替代位標記，這可以是一個列表，列表中可以使用逗號分隔，或者使用 "-" 進行范圍標記，例如：0,5,7,9
-h, --help
列印幫助信息
-V, --version
列印版本信息

如果需要設定，那麼需要擁有 CAP_SYS_NICE 的許可權；如果要獲取設定信息，沒有任何許可權要求。

taskset 命令屬於 util-linux-ng 包，可以使用 yum 直接安裝。

『叄』 請教linux下用戶態進程調度問題

在進行Linux系統操作的時候，有時候會遇到一次用戶態進程死循環，即系統反應遲鈍、進程掛死等問題，那麼遇到這些問題又該如何解決呢？下面小編就給大家介紹下一次用戶態進程死循環的問題該如何處理。
Linux下如何處理一次用戶態進程死循環問題
1、問題現象
業務進程（用戶態多線程程序）掛死，操作系統反應遲鈍，系統日誌沒有任何異常。從進程的內核態堆棧看，看似所有線程都卡在了內核態的如下堆棧流程中：
［root@vmc116 ~］# cat /proc/27007/task/11825/stack
［《ffffffff8100baf6》］ retint_careful+0x14/0x32
［《ffffffffffffffff》］ 0xffffffffffffffff
2、問題分析
1）內核堆棧分析
從內核堆棧看，所有進程都阻塞在 retint_careful上，這個是中斷返回過程中的流程，代碼（匯編）如下：
entry_64.S
代碼如下：
ret_from_intr：
DISABLE_INTERRUPTS（CLBR_NONE）
TRACE_IRQS_OFF
decl PER_CPU_VAR（irq_count）
/* Restore saved previous stack */
popq %rsi
CFI_DEF_CFA rsi，SS+8-RBP /* reg/off reset after def_cfa_expr */
leaq ARGOFFSET-RBP（%rsi）， %rsp
CFI_DEF_CFA_REGISTER rsp
CFI_ADJUST_CFA_OFFSET RBP-ARGOFFSET
。。。
retint_careful：
CFI_RESTORE_STATE
bt $TIF_NEED_RESCHED，%edx
jnc retint_signal
TRACE_IRQS_ON
ENABLE_INTERRUPTS（CLBR_NONE）
pushq_cfi %rdi
SCHEDULE_USER
popq_cfi %rdi
GET_THREAD_INFO（%rcx）
DISABLE_INTERRUPTS（CLBR_NONE）
TRACE_IRQS_OFF
jmp retint_check
這其實是用戶態進程在用戶態被中斷打斷後，從中斷返回的流程，結合retint_careful+0x14/0x32，進行反匯編，可以確認阻塞的點其實就在
SCHEDULE_USER
這其實就是調用schele（）進行調度，也就是說當進程走到中斷返回的流程中時，發現需要調度（設置了TIF_NEED_RESCHED），於是在這里發生了調度。
有一個疑問：為什麼在堆棧中看不到schele（）這一級的棧幀呢？
因為這里是匯編直接調用的，沒有進行相關棧幀壓棧和上下文保存操作。
2）進行狀態信息分析
從top命令結果看，相關線程實際一直處於R狀態，CPU幾乎完全耗盡，而且絕大部分都消耗在用戶態：
［root@vmc116 ~］# top
top - 09:42:23 up 16 days， 2:21， 23 users， load average： 84.08， 84.30， 83.62
Tasks： 1037 total， 85 running， 952 sleeping， 0 stopped， 0 zombie
Cpu（s）： 97.6%us， 2.2%sy， 0.2%ni， 0.0%id， 0.0%wa， 0.0%hi， 0.0%si， 0.0%st
Mem： 32878852k total， 32315464k used， 563388k free， 374152k buffers
Swap： 35110904k total， 38644k used， 35072260k free， 28852536k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27074 root 20 0 5316m 163m 14m R 10.2 0.5 321:06.17 z_itask_templat
27084 root 20 0 5316m 163m 14m R 10.2 0.5 296:23.37 z_itask_templat
27085 root 20 0 5316m 163m 14m R 10.2 0.5 337:57.26 z_itask_templat
27095 root 20 0 5316m 163m 14m R 10.2 0.5 327:31.93 z_itask_templat
27102 root 20 0 5316m 163m 14m R 10.2 0.5 306:49.44 z_itask_templat
27113 root 20 0 5316m 163m 14m R 10.2 0.5 310:47.41 z_itask_templat
25730 root 20 0 5316m 163m 14m R 10.2 0.5 283:03.37 z_itask_templat
30069 root 20 0 5316m 163m 14m R 10.2 0.5 283:49.67 z_itask_templat
13938 root 20 0 5316m 163m 14m R 10.2 0.5 261:24.46 z_itask_templat
16326 root 20 0 5316m 163m 14m R 10.2 0.5 150:24.53 z_itask_templat
6795 root 20 0 5316m 163m 14m R 10.2 0.5 100:26.77 z_itask_templat
27063 root 20 0 5316m 163m 14m R 9.9 0.5 337:18.77 z_itask_templat
27065 root 20 0 5316m 163m 14m R 9.9 0.5 314:24.17 z_itask_templat
27068 root 20 0 5316m 163m 14m R 9.9 0.5 336:32.78 z_itask_templat
27069 root 20 0 5316m 163m 14m R 9.9 0.5 338:55.08 z_itask_templat
27072 root 20 0 5316m 163m 14m R 9.9 0.5 306:46.08 z_itask_templat
27075 root 20 0 5316m 163m 14m R 9.9 0.5 316:49.51 z_itask_templat
。。。
3）進程調度信息
從相關線程的調度信息看：
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15681811525768 129628804592612 3557465
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15682016493013 129630684625241 3557509
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15682843570331 129638127548315 3557686
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15683323640217 129642447477861 3557793
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15683698477621 129645817640726 3557875
發現相關線程的調度統計一直在增加，說明相關線程一直是在被調度運行的，結合其狀態也一直是R，推測很可能在用戶態發生了死循環（或者非睡眠死鎖）。
這里又有問題：為什麼從top看每個線程的CPU佔用率只有10%左右，而不是通常看到的死循環進程導致的100%的佔用率？
因為線程數很多，而且優先順序都一樣，根據CFS調度演算法，會平均分配時間片，不會讓其中一個線程獨佔CPU。結果為多個線程間輪流調度，消耗掉了所有的cpu。。
另一個問題：為什麼這種情況下，內核沒有檢測到softlockup？
因為業務進程的優先順序不高，不會影響watchdog內核線程（最高優先順序的實時線程）的調度，所以不會產生softlockup的情況。
再一個問題：為什麼每次查看線程堆棧時，總是阻塞在retint_careful，而不是其它地方？
因為這里（中斷返回的時候）正是調度的時機點，在其它時間點不能發生調度（不考慮其它情況~），而我們查看線程堆棧的行為，也必須依賴於進程調度，所以我們每次查看堆棧時，正是查看堆棧的進程（cat命令）得到調度的時候，這時正是中斷返回的時候，所以正好看到的阻塞點為retint_careful。
4）用戶態分析
從上面的分析看，推測應該是用戶態發生了死鎖。
用戶態確認方法：
部署debug信息，然後gdb attach相關進程，確認堆棧，並結合代碼邏輯分析。
最終確認該問題確為用戶態進程中產生了死循環。

『肆』 Linux中常見IO調度器

對於磁碟I/O，Linux提供了cfq, deadline和noop三種調度策略

考慮到硬體配置、實際應用場景（讀寫比例、順序還是隨機讀寫）的差異，上面的簡單解釋對於實際選擇沒有太大幫助，實際該選擇哪個基本還是要實測來驗證。不過下面幾條說明供參考：

NOOP全稱No Operation,中文名稱電梯式調度器，該演算法實現了最簡單的FIFO隊列，所有I/O請求大致按照先來後到的順序進行操作。NOOP實現了一個簡單的FIFO隊列,它像電梯的工作方式一樣對I/O請求進行組織。它是基於先入先出（FIFO）隊列概念的 Linux 內核里最簡單的I/O 調度器。此調度程序最適合於固態硬碟。

Deadline翻譯成中文是截止時間調度器，是對Linus Elevator的一種改進，它避免有些請求太長時間不能被處理。另外可以區分對待讀操作和寫操作。DEADLINE額外分別為讀I/O和寫I/O提供了FIFO隊列。

Deadline對讀寫request進行了分類管理，並且在調度處理的過程中讀請求具有較高優先順序。這主要是因為讀請求往往是同步操作，對延遲時間比較敏感，而寫操作往往是非同步操作，可以盡可能的將相鄰訪問地址的請求進行合並，但是，合並的效率越高，延遲時間會越長。因此，為了區別對待讀寫請求類型，deadline採用兩條鏈表對讀寫請求進行分類管理。但是，引入分類管理之後，在讀優先的情況下，寫請求如果長時間得到不到調度，會出現餓死的情況，因此，deadline演算法考慮了寫餓死的情況，從而保證在讀優先調度的情況下，寫請求不會被餓死。

總體來講，deadline演算法對request進行了優先權控制調度，主要表現在如下幾個方面：

CFQ全稱Completely Fair Scheler ，中文名稱完全公平調度器，它是現在許多 Linux 發行版的默認調度器，CFQ是內核默認選擇的I/O調度器。它將由進程提交的同步請求放到多個進程隊列中，然後為每個隊列分配時間片以訪問磁碟。 對於通用的伺服器是最好的選擇，CFQ均勻地分布對I/O帶寬的訪問 。CFQ為每個進程和線程，單獨創建一個隊列來管理該進程所產生的請求,以此來保證每個進程都能被很好的分配到I/O帶寬，I/O調度器每次執行一個進程的4次請求。該演算法的特點是按照I/O請求的地址進行排序，而不是按照先來後到的順序來進行響應。簡單來說就是給所有同步進程分配時間片，然後才排隊訪問磁碟。

多隊列無操作I / O調度程序。不對請求進行重新排序，最小的開銷。NVME等快速隨機I / O設備的理想選擇。

這是對最後期限I / O調度程序的改編，但設計用於 多隊列設備。一個出色的多面手，CPU開銷相當低。

『伍』 linux進程、線程及調度演算法（二）

執行一個 ，但是只要任何修改，都造成分裂如，修改了chroot,寫memory，mmap，sigaction 等。

p1 是一個 task_struct, p2 也是一個 task_struct. linux內核的調度器只認得task_struck （不管你是進程還是線程）, 對其進行調度。
p2 的task_struck 被創建出來後，也有一份自己的資源。但是這些資源會短暫的與p1 相同。
進程是區分資源的單位，你的資源是我的資源，那從概念上將就不叫進程。

其他資源都好分配，唯一比較難的是內存資源的重新分配。

非常簡單的程序，但是可以充分說明 COW。
結果：10 -> 20 -> 10

COW 是嚴重依賴於CPU中的MMU。CPU如果沒有 MMU,fork 是不能工作的。
在沒有mmu的CPU中，不可能執行COW 的，所以只有vfork
vfork與fork相比的不同

P2沒有自己的 task_struct, 也就是說P1 的內存資源 就是 P2的內存資源。

結果 10,20,20

vfork：

vfork 執行上述流程，P2也只是指向了P1的mm，那麼將這個vfork 放大，其餘的也全部clone，共同指向P1，那麼就是線程的屬性了。
phtread_create -> Clone()

P1 P2 在內核中都是 task_struct. 都可以被調度。共享資源可調度，即線程。 這就是線程為什麼也叫做輕量級進程
不需要太糾結線程和進程的區別。

4651 ： TGID
4652, 4653 tid 內核中 task_struct 真正的pid

linux 總是白發人 送 黑發人。如果父進程在子進程推出前掛掉了。那麼子進程應該怎麼辦？

p3 -> init， p5 -> subreaper

每一個孤兒都會找最近的火葬場
可以設置進程的屬性，將其變為subreaper，會像1號進程那樣收養孤兒進程。

linux的進程睡眠依靠等待隊列，這樣的機制類似與涉及模式中的訂閱與發布。
睡眠，分兩種

每一個進程都是創建出來的，那麼第一個進程是誰創建的呢？
init 進程是被linux的 0 進程 創建出來的。開機創建。

父進程就是 0 號進程，但在pstree，是看不到0進程的。因為0進程創建子進程後，就退化成了idle進程。
idle進程是 linux內核里，特殊調度類。 所有進程都睡眠停止 ，則調度idle進程，進入到 wait for interrupte 等中斷。此時 cpu及其省電，除非來一個中斷，才能再次被喚醒。
喚醒後的任何進程，從調度的角度上說，都比idle進程地位高。idle是調度級別最最低的進程。
0 進程 一跑，則進入等中斷。一旦其他進程被喚醒，就輪不到 0進程了。
所有進程都睡了，0就上來，則cpu需要進入省電模式

『陸』 linux 下 進程和線程的區別

線程是指進程內的一個執行單元,也是進程內的可調度實體.
與進程的區別:
(1)地址空間:進程內的一個執行單元;進程至少有一個線程;它們共享進程的地址空間;而進程有自己獨立的地址空間;
(2)資源擁有:進程是資源分配和擁有的單位,同一個進程內的線程共享進程的資源
(3)線程是處理器調度的基本單位,但進程不是.
4)二者均可並發執行.
進程和線程都是由操作系統所體會的程序運行的基本單元，系統利用該基本單元實現系統對應用的並發性。進程是系統進行資源分配和調度的一個獨立單位。線程是進程的一個實體，是CPU調度和分派的基本單位，線程自己基本上不擁有系統資源，只擁有一點在運行中必不可少的資源（如程序計數器，一組寄存器和棧），但是它可與同屬一個進程的其他的線程共享進程所擁有的全部資源。一個線程可以創建和撤銷另一個線程，同一個進程中的多個線程之間可以並發執行。

2.進程和應用程序的區別？

進程與應用程序的區別在於應用程序作為一個靜態文件存儲在計算機系統的硬碟等存儲空間中，而進程則是處於動態條件下由操作系統維護的系統資源管理實體。
C、C++、Java等語言編寫的源程序經相應的編譯器編譯成可執行文件後，提交給計算機處理器運行。這時，處在可執行狀態中的應用程序稱為進程。從用戶角度來看，進程是應用程序的一個執行過程。從操作系統核心角度來看，進程代表的是操作系統分配的內存、CPU時間片等資源的基本單位，是為正在運行的程序提供的運行環境。進程與應用程序的區別在於應用程序作為一個靜態文件存儲在計算機系統的硬碟等存儲空間中，而進程則是處於動態條件下由操作系統維護的系統資源管理實體。多任務環境下應用程序進程的主要特點包括： ●進程在執行過程中有內存單元的初始入口點，並且進程存活過程中始終擁有獨立的內存地址空間； ●進程的生存期狀態包括創建、就緒、運行、阻塞和死亡等類型； ●從應用程序進程在執行過程中向CPU發出的運行指令形式不同，可以將進程的狀態分為用戶態和核心態。處於用戶態下的進程執行的是應用程序指令、處於核心態下的應用程序進程執行的是操作系統指令

3.進程與Java線程的區別

應用程序在執行過程中存在一個內存空間的初始入口點地址、一個程序執行過程中的代碼執行序列以及用於標識進程結束的內存出口點地址，在進程執行過程中的每一時間點均有唯一的處理器指令與內存單元地址相對應。
Java語言中定義的線程（Thread）同樣包括一個內存入口點地址、一個出口點地址以及能夠順序執行的代碼序列。但是進程與線程的重要區別在於線程不能夠單獨執行，它必須運行在處於活動狀態的應用程序進程中，因此可以定義線程是程序內部的具有並發性的順序代碼流。 Unix操作系統和Microsoft Windows操作系統支持多用戶、多進程的並發執行，而Java語言支持應用程序進程內部的多個執行線程的並發執行。多線程的意義在於一個應用程序的多個邏輯單元可以並發地執行。但是多線程並不意味著多個用戶進程在執行，操作系統也不把每個線程作為獨立的進程來分配獨立的系統資源。進程可以創建其子進程，子進程與父進程擁有不同的可執行代碼和數據內存空間。而在用於代表應用程序的進程中多個線程共享數據內存空間，但保持每個線程擁有獨立的執行堆棧和程序執行上下文（Context）。
需要注意的是：在應用程序中使用多線程不會增加 CPU 的數據處理能力。只有在多CPU 的計算機或者在網路計算體系結構下，將Java程序劃分為多個並發執行線程後，同時啟動多個線程運行，使不同的線程運行在基於不同處理器的Java虛擬機中，才能提高應用程序的執行效率。 另外，如果應用程序必須等待網路連接或資料庫連接等數據吞吐速度相對較慢的資源時，多線程應用程序是非常有利的。基於Internet的應用程序有必要是多線程類型的，例如，當開發要支持大量客戶機的伺服器端應用程序時，可以將應用程序創建成多線程形式來響應客戶端的連接請求，使每個連接用戶獨佔一個客戶端連接線程。這樣，用戶感覺伺服器只為連接用戶自己服務，從而縮短了伺服器的客戶端響應時間。 三、Java語言的多線程程序設計方法

『柒』 如何查看linux線程的調度策略

方法一：PS
在ps命令中，「-T」選項可以開啟線程查看。下面的命令列出碰態了由進程號為<棚帶pid>的進程鏈吵蘆創建的所有線程。
1.$ ps -T -p <pid>

「SID」欄表示線程ID，而「CMD」欄則顯示了線程名稱。

方法二： Top
top命令可以實時顯示各個線程情況。要在top輸出中開啟線程查看，請調用top命令的「-H」選項，該選項會列出所有Linux線程。在top運行時，你也可以通過按「H」鍵將線程查看模式切換為開或關。
1.$ top -H

要讓top輸出某個特定進程<pid>並檢查該進程內運行的線程狀況：
$ top -H -p <pid>

『捌』 linux調度是基於進程還是線程

在LINUX系統之中，被調度的應該是進程。因為只有進程才擁有一個獨立的上下文環境，是分配系統資源的最小單位……而線程在SMP體系中加速了執行的效率……
在LINUX之中，線程也可稱作輕量級進程，它能享有自己的堆棧，線程ID等獨立資源，但大多還是要依賴其創建進程，比如地址空間，信號，文件句柄……

『玖』 Linux進程與線程的區別和聯系

進程中可包含多個線程，最少1個，進程可控制進程內線程的運行暫停及結束，線程可共享進程全局變數，進程與進程是單獨個體，相互不能直接訪問各自線程及全局變數

『拾』 linux進程、線程及調度演算法（三）

調度策略值得是大家都在ready時，並且CPU已經被調度時，決定誰來運行，誰來被調度。

兩者之間有一定矛盾。
響應的優化，意味著高優先順序會搶占優先順序，會花時間在上下文切換，會影響吞吐。
上下文切換的時間是很短的，幾微妙就能搞定。上下文切換本身對吞吐並多大影響， 重要的是，切換後引起的cpu 的 cache miss.
每次切換APP, 數據都要重新load一次。
Linux 會盡可能的在響應與吞吐之間尋找平衡。比如在編譯linux的時候，會讓你選擇 kernal features -> Preemption model.
搶占模型會影響linux的調度演算法。

所以 ARM 的架構都是big+LITTLE， 一個很猛CPU+ 多個 性能較差的 CPU, 那麼可以把I/O型任務的調度 放在 LITTLE CPU上。需要計算的放在big上。

早期2.6 內核將優先順序劃分了 0-139 bit的優先順序。數值越低，優先順序越高。0-99優先順序 都是 RT（即時響應）的 ，100-139都是非RT的，即normal。
調度的時候 看哪個bitmap 中的 優先順序上有任務ready。可能多個任務哦。

在普通優先順序線程調度中，高優先順序並不代表對低優先順序的絕對優勢。會在不同優先順序進行輪轉。
100 就是比101高，101也會比102高，但100 不會堵著101。
眾屌絲進程在輪轉時，優先順序高的：

初始設置nice值為0，linux 會探測 你是喜歡睡眠，還是幹活。越喜歡睡，linux 越獎勵你，優先順序上升（nice值減少）。越喜歡幹活，優先順序下降（nice值增加）。所以一個進程在linux中，干著干著 優先順序越低，睡著睡著 優先順序越高。

後期linux補丁中

紅黑樹，數據結構， 左邊節點小於右邊節點
同時兼顧了 CPU/IO 和 nice。
數值代表著 進程運行到目前為止的virtual runtime 時間。

（pyhsical runtime） / weight * 1024(系數)。
優先調度 節點值（vruntime）最小的線程。權重weight 其實有nice 來控制。

一個線程一旦被調度到，則物理運行時間增加，vruntime增加，往左邊走。
weight的增加，也導致vruntime減小，往右邊走。
總之 CFS讓線程 從左滾到右，從右滾到左。即照顧了I/O(喜歡睡，分子小) 也 照顧了 nice值低（分母高）.所以 由喜歡睡，nice值又低的線程，最容易被調度到。
自動調整，無需向nice一樣做出獎勵懲罰動作，個人理解權重其實相當於nice

但是 此時 來一個 0-99的線程，進行RT調度，都可以瞬間秒殺你！因為人家不是普通的，是RT的!

一個多線程的進程中，每個線程的調度的策略 如 fifo rr normal, 都可以不同。每一個的優先順序都可以不一樣。
實驗舉例, 創建2個線程，同時開2個：

運行2次，創建兩個進程
sudo renice -n -5(nice -5級別) -g(global)， 會明顯看到 一個進程的CPU佔用率是另一個的 3倍。

為什麼cpu都已經達到200%，為什麼系統不覺得卡呢？因為，我們的線程在未設置優先順序時，是normal調度模式，且是 CPU消耗型 調度級別其實不高。

利用chrt工具，可以將進程 調整為 50 從normal的調度策略 升為RT （fifo）級別的調度策略，會出現：

chrt , nice renice 的調度策略 都是以線程為單位的，以上 設置的將進程下的所有線程進行設置nice值
線程是調度單位，進程不是，進程是資源封裝單位！

兩個同樣死循環的normal優先順序線程，其中一個nice值降低，該線程的CPU 利用率就會比另一個CPU的利用率高。