當前位置：首頁 > 运维知识 > linux >内容正文

linux

嵌入式系统Linux内核开发工程师必须掌握的三十道题

發(fā)布時間：2023/12/20 linux 47 豆豆

生活随笔收集整理的這篇文章主要介紹了嵌入式系统Linux内核开发工程师必须掌握的三十道题小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

嵌入式系統(tǒng)Linux內(nèi)核開發(fā)工程師必須掌握的三十道題?

? ? 如果你能正確回答以下問題并理解相關(guān)知識點原理，那么你就可以算得上是基本合格的Linux內(nèi)核開發(fā)工程師，試試看！

? ? 1) Linux中主要有哪幾種內(nèi)核鎖？

Linux的內(nèi)核鎖主要是自旋鎖和信號量。

自旋鎖最多只能被一個可執(zhí)行線程持有，如果一個執(zhí)行線程試圖請求一個已被爭用（已經(jīng)被持有）的自旋鎖，那么這個線程就會一直進行忙循環(huán)——旋轉(zhuǎn)——等待鎖重新可用。要是鎖未被爭用，請求它的執(zhí)行線程便能立刻得到它并且繼續(xù)進行。自旋鎖可以在任何時刻防止多于一個的執(zhí)行線程同時進入臨界區(qū)。

Linux中的信號量是一種睡眠鎖。如果有一個任務(wù)試圖獲得一個已被持有的信號量時，信號量會將其推入等待隊列，然后讓其睡眠。這時處理器獲得自由去執(zhí)行其它代碼。當持有信號量的進程將信號量釋放后，在等待隊列中的一個任務(wù)將被喚醒，從而便可以獲得這個信號量。

信號量的睡眠特性，使得信號量適用于鎖會被長時間持有的情況；只能在進程上下文中使用，因為中斷上下文中是不能被調(diào)度的；另外當代碼持有信號量時，不可以再持有自旋鎖。

? ? 2) Linux中的用戶模式和內(nèi)核模式是什么含意？

linux中內(nèi)核本身處于內(nèi)核模式，應(yīng)用程序處于用戶模式。

內(nèi)核模式的代碼可以無限制地訪問所有處理器指令集以及全部內(nèi)存和I/O空間。如果用戶模式的進程要享有此特權(quán)，它必須通過系統(tǒng)調(diào)用向設(shè)備驅(qū)動程序或其他內(nèi)核模式的代碼發(fā)出請求。另外，用戶模式的代碼允許發(fā)生缺頁，而內(nèi)核模式的代碼則不允許。

在2.4和更早的內(nèi)核中，僅僅用戶模式的進程可以被上下文切換出局，由其他進程搶占。除非發(fā)生以下兩種情況，否則內(nèi)核模式代碼可以一直獨占CPU：

(1) 它自愿放棄CPU；

(2) 發(fā)生中斷或異常。

2.6內(nèi)核引入了內(nèi)核搶占，大多數(shù)內(nèi)核模式的代碼也可以被搶占。

? ? 3) 怎樣申請大塊內(nèi)核內(nèi)存？

?在Linux內(nèi)核環(huán)境下，申請大塊內(nèi)存的成功率隨著系統(tǒng)運行時間的增加而減少，雖然可以通過vmalloc系列調(diào)用申請物理不連續(xù)但虛擬地址連續(xù)的內(nèi)存，但畢竟其使用效率不高且在32位系統(tǒng)上vmalloc的內(nèi)存地址空間有限。所以，一般的建議是在系統(tǒng)啟動階段申請大塊內(nèi)存，但是其成功的概率也只是比較高而已，而不是100%。如果程序真的比較在意這個申請的成功與否，只能退用“啟動內(nèi)存”（Boot Memory）。下面就是申請并導(dǎo)出啟動內(nèi)存的一段示例代碼：?

void* x_bootmem = Null;

EXPORT_SYMBOL(x_bootmem);?

unsigned long x_bootmem_size = 0;

EXPORT_SYMBOL(x_bootmem_size);?

static int __init x_bootmem_setup(char *str)

{

? ?x_bootmem_size = memparse(str, &str);

? ?x_bootmem = alloc_bootmem(x_bootmem_size);

? ?printk("Reserved %lu bytes from %p for x\n", x_bootmem_size, x_bootmem);?

? ?return 1;

}

__setup("x-bootmem=", x_bootmem_setup);

? ? ? 可見其應(yīng)用還是比較簡單的，不過利弊總是共生的，它不可避免也有其自身的限制：內(nèi)存申請代碼只能連接進內(nèi)核，不能在模塊中使用。被申請的內(nèi)存不會被頁分配器和slab分配器所使用和統(tǒng)計，也就是說它處于系統(tǒng)的可見內(nèi)存之外，即使在將來的某個地方你釋放了它。

? ? ? 一般用戶只會申請一大塊內(nèi)存，如果需要在其上實現(xiàn)復(fù)雜的內(nèi)存管理則需要自己實現(xiàn)。在不允許內(nèi)存分配失敗的場合，通過啟動內(nèi)存預(yù)留內(nèi)存空間將是我們唯一的選擇。

? ? 4) 用戶進程間通信主要哪幾種方式？

# 管道( pipe )：管道是一種半雙工的通信方式，數(shù)據(jù)只能單向流動，而且只能在具有親緣關(guān)系的進程間使用。進程的親緣關(guān)系通常是指父子進程關(guān)系。

# 有名管道 (named pipe) ：有名管道也是半雙工的通信方式，但是它允許無親緣關(guān)系進程間的通信。

# 信號量( semophore ) ：信號量是一個計數(shù)器，可以用來控制多個進程對共享資源的訪問。它常作為一種鎖機制，防止某進程正在訪問共享資源時，其他進程也訪問該資源。因此，主要作為進程間以及同一進程內(nèi)不同線程之間的同步手段。

# 消息隊列( message queue ) ：消息隊列是由消息的鏈表，存放在內(nèi)核中并由消息隊列標識符標識。消息隊列克服了信號傳遞信息少、管道只能承載無格式字節(jié)流以及緩沖區(qū)大小受限等缺點。

# 信號 ( sinal ) ：信號是一種比較復(fù)雜的通信方式，用于通知接收進程某個事件已經(jīng)發(fā)生。

# 共享內(nèi)存( shared memory ) ：共享內(nèi)存就是映射一段能被其他進程所訪問的內(nèi)存，這段共享內(nèi)存由一個進程創(chuàng)建，但多個進程都可以訪問。共享內(nèi)存是最快的 IPC 方式，它是針對其他進程間通信方式運行效率低而專門設(shè)計的。它往往與其他通信機制，如信號兩，配合使用，來實現(xiàn)進程間的同步和通信。

# 套接字( socket ) ：套解口也是一種進程間通信機制，與其他通信機制不同的是，它可用于不同及其間的進程通信。

? ? 5) 通過伙伴系統(tǒng)申請內(nèi)核內(nèi)存的函數(shù)有哪些？

? ? 6) 通過slab分配器申請內(nèi)核內(nèi)存的函數(shù)有？

? ? 7) Linux的內(nèi)核空間和用戶空間是如何劃分的（以32位系統(tǒng)為例）？

Linux將4G的地址劃分為用戶空間和內(nèi)核空間兩部分。在Linux內(nèi)核的低版本中（2.0.X），通常0-3G為用戶空間，3G-4G為內(nèi)核空間。這個分界點是可以改動的。?

正是這個分界點的存在，限制了Linux可用的最大內(nèi)存為2G.而且要通過重編內(nèi)核，調(diào)整這個分界點才能達到。實際上還可以有更好的方法來解決這個問題。由于內(nèi)核空間與用戶空間互不重合，所以可以用段機制提供的保護功能來保護內(nèi)核級代碼。?

2.2.X版的內(nèi)核對此進行了改動。這樣內(nèi)核空間擴張到了4G。從表面上看內(nèi)核的基地址變?yōu)榱?，但實際上，內(nèi)核通常仍在虛址3G以上。?

用戶空間在2.2.X中從直觀上變?yōu)?-4G，讓人迷惑，不是可以直接訪問內(nèi)核了？?

其實不然，同過使用頁機制提供的保護，阻止了用戶程序訪問內(nèi)核空間。

? ? 8) vmalloc()申請的內(nèi)存有什么特點？

? ? 9) 用戶程序使用malloc()申請到的內(nèi)存空間在什么范圍？

K&R 的書第8章最后的部分有論述

簡單的說就是：內(nèi)存是分散成一些小塊的，malloc管理的內(nèi)存是通過鏈表的

方式把這些塊串在一起，以這些內(nèi)存的起始地址排序組織的，相鄰的內(nèi)存塊如

果尾首地址連續(xù)，那就把它們合并為一塊，當你申請一定大小的內(nèi)存時

以first fit模式,在內(nèi)存鏈中找第一個大于你需要大小的內(nèi)存，返回內(nèi)存指針

以best fit模式，要遍歷整個內(nèi)存鏈，找剛好最接近但大于所需要大小的內(nèi)存

當然這是出于對內(nèi)存不浪費的考慮，效率是有損失.釋放的話相反，把內(nèi)存放回

內(nèi)存管理鏈中，可能的話合并相鄰的內(nèi)存碎片。避免內(nèi)存過于零散

Linux下malloc函數(shù)主要用來在用戶空間從heap申請內(nèi)存，申請成功返回指向所分配內(nèi)存的指針，申請失敗返回NULL。默認情況下，Linux內(nèi)核使用“樂觀的”分配內(nèi)存策略，首先粗略估計系統(tǒng)可使用的內(nèi)存數(shù)，然后分配內(nèi)存，但是在使用的時候才真正把這塊分配的內(nèi)存給你。這樣一來，即使用malloc申請內(nèi)存沒有返回NULL，你也不一定能完全使用這塊內(nèi)存，特別是在一次或連續(xù)多次申請很多內(nèi)存的時候。

如果一直連續(xù)用malloc申請內(nèi)存，而不真正使用，所申請的內(nèi)存總數(shù)可以超過真正可以使用的內(nèi)存數(shù)。但是當真正使用這塊內(nèi)存，比如用memset或bzero函數(shù)一次性把所申請到的大塊內(nèi)存“使用掉”，Linux系統(tǒng)就會Out Of Memory，這個時候OOM Killer就會kill掉用戶空間的其他進程來騰出更多可使用內(nèi)存。

OOM Killer根據(jù)OOM score來決定kill哪個進程，OOM score可以看/proc/<PID>/oom_score，score由badness函數(shù)計算得出，根據(jù)進程運行時間長短，進程優(yōu)先級，進程所使用的內(nèi)存數(shù)等等。可以通過/proc/<PID>/oom_adj來干預(yù)計算socre，這個值的取值范圍是-17～15，如果是-17該進程就永遠不會被kill（這個可能也和內(nèi)核版本有關(guān)，不見得所有內(nèi)核版本都支持，得實際試試）。

“默認情況”Linux是這種做的，“默認情況”是指/proc/sys/vm/overcommit_memory為0的時候。這個參數(shù)也可以調(diào)整，如果為1表示“來著不拒”，只要你malloc過來申請，我啥都不做，立馬給你分配內(nèi)存，這樣的話性能就會有大幅度的提高；如果為2表示Linux會精確計算所有可使用的內(nèi)存和所申請的內(nèi)存，如果所申請的超過的可使用的內(nèi)存數(shù)就返回NULL。可使用的內(nèi)存值計算方法，虛擬內(nèi)存（swap）+ /proc/sys/vm/overcommit_memory（百分比） × 物理內(nèi)存。/proc/sys/vm/overcommit_memory默認值為50,計算起來就是50%的物理內(nèi)存數(shù)。

Linux自身內(nèi)核會占一部分內(nèi)存，還有buffer/cache所占用的內(nèi)存，所以實際上能被malloc申請后使用的內(nèi)存并非物理內(nèi)存大小，demsg的輸出里面包含了相關(guān)信息（如果看不到，可能是被別的信息沖掉了，重啟系統(tǒng)，在系統(tǒng)起來后馬上看）：

Memory: 2071220k/2097152k available (2122k kernel code, 24584k reserved, 884k data, 228k init, 1179584k highmem)

? ? 10) 在支持并使能MMU的系統(tǒng)中，Linux內(nèi)核和用戶程序分別運行在物理地址模式還是虛擬地址模式？

? ? 11) ARM處理器是通過幾級也表進行存儲空間映射的？

? ? 12) Linux是通過什么組件來實現(xiàn)支持多種文件系統(tǒng)的？

? ? 13) Linux虛擬文件系統(tǒng)的關(guān)鍵數(shù)據(jù)結(jié)構(gòu)有哪些？（至少寫出四個）

? ? 14) 對文件或設(shè)備的操作函數(shù)保存在那個數(shù)據(jù)結(jié)構(gòu)中？

? ? 15) Linux中的文件包括哪些？

我們在Linux中常用的文件系統(tǒng)主要有ext3、ext2及reiserfs。Linux目前幾乎支持所有的Unix類的文件系統(tǒng)，除了我們在安裝Linux操作系統(tǒng)時所要選擇的ext3、reiserfs和ext2外，還支持蘋果MACOS的HFS，也支持其它Unix操作系統(tǒng)的文件系統(tǒng)，比如XFS、JFS、Minix fs 及UFS等，您可以在kernel的源碼中查看；如果您想要讓系統(tǒng)支持哪些的文件系統(tǒng)得需要把該文件系統(tǒng)編譯成模塊或置入內(nèi)核；

當然Linux也支持Windows文件系統(tǒng)NTFST和fat，但不支持NTFS文件系統(tǒng)的寫入；支持fat文件系統(tǒng)的讀寫。現(xiàn)在還有新的ext4文件系統(tǒng)。

? ? 16) 創(chuàng)建進程的系統(tǒng)調(diào)用有那些？

創(chuàng)建進程的調(diào)用：

啟動新進程：int system(const char *string) ?【include<stdlib.h>】

替換進程映像：int execl（）；int execlv（）；int execlp（）

? ? ? ? ? ? ? int execv();execvp();int execve() 【include<unistd.h>】

復(fù)制進程 fork

? ? 17) 調(diào)用schedule()進行進程切換的方式有幾種？

? ? 18) Linux調(diào)度程序是根據(jù)進程的動態(tài)優(yōu)先級還是靜態(tài)優(yōu)先級來調(diào)度進程的？?

三、調(diào)度策略

1. 進程優(yōu)先級

(1) 優(yōu)先級的計算

前面已經(jīng)說過，優(yōu)先級由兩部分構(gòu)成，一是靜態(tài)優(yōu)先級static_prio，一是動態(tài)優(yōu)先

級prio。靜態(tài)優(yōu)先級在進程創(chuàng)建的時候就被賦值，并且不變（除非用系統(tǒng)調(diào)用改變進

程的nice值）；而進程的動態(tài)優(yōu)先級則是跟static_prio和sleep_avg有關(guān)。對于實時

進程的優(yōu)先級在創(chuàng)建的時候就確定了，而且一旦確定以后就不再改變，所以下面部分

僅對于非實時進程而言。具體的計算由函數(shù)effecitve_prio()（kernel/sched.c）完

成。

函數(shù)將進程的sleep_avg映射成范圍是-MAX_BONUS/2 ~ MAX_BONUS/2的變量bonus，而

MAX_BONUS是等于，可見sleep_avg僅能影響的優(yōu)先級范圍在-5 ~ 5之間。具體的映

射是由以下規(guī)則完成的：

? ? ? 那么進程的動態(tài)優(yōu)先級就等于：（當然必須在MAX_RT_PRIO和MAX_PRIO-1之間

）。可見，sleep_avg和bonus是一個線性關(guān)系。進程的sleep_avg越大，bonus越大，

從而進程的動態(tài)優(yōu)先級也就越高。

(2) 何時計算優(yōu)先級

計算進程的動態(tài)優(yōu)先級一般調(diào)用兩個函數(shù)，一個是effective_prio()，一個是

recalc_task_prio()。函數(shù)recalc_task_prio ()先要根據(jù)進程被喚醒前的狀態(tài)

（即actived）、interactive_credit等來計算進程的sleep_avg

（詳見"平均等待時間sleep_avg"一節(jié)），在最后調(diào)用effective_prio()來計算函數(shù)

的動態(tài)優(yōu)先級。總的來說，有以下幾種情況需要計算進程的優(yōu)先級：

a. 創(chuàng)建新進程，使用函數(shù)effective_prio()（因為此時進程尚未進行調(diào)度，沒有

sleep_avg和interactive_credit可言）；

b. 喚醒等待進程時，使用函數(shù)recalc_task_prio ()來計算進程動態(tài)優(yōu)先級。

c. 進程用完時間片以后，被重新插入到active array或者expired array的時候需要

重新計算動態(tài)優(yōu)先級，以便將進程插入到隊列的相應(yīng)位置。此時，使用函數(shù)

effective_prio()；

d. 其他情況，如IDLE進程初始化等時候。

2. 進程時間片

(1) 時間片的計算

進程的時間片time_slice是基于進程靜態(tài)優(yōu)先級的，靜態(tài)優(yōu)先級越高（值越小），時

間片就越大。計算時間片是同過函數(shù)task_timeslice()（kernel/sched.c）來完成的

MAX_BONUS是等于，可見sleep_avg僅能影響的優(yōu)先級范圍在-5 ~ 5之間。具體的映

射是由以下規(guī)則完成的：

? ? ? 那么進程的動態(tài)優(yōu)先級就等于：（當然必須在MAX_RT_PRIO和MAX_PRIO-1之間

）。可見，sleep_avg和bonus是一個線性關(guān)系。進程的sleep_avg越大，bonus越大，

從而進程的動態(tài)優(yōu)先級也就越高。

(2) 何時計算優(yōu)先級

計算進程的動態(tài)優(yōu)先級一般調(diào)用兩個函數(shù)，一個是effective_prio()，一個是

recalc_task_prio()。函數(shù)recalc_task_prio ()先要根據(jù)進程被喚醒前的狀態(tài)

（即actived）、interactive_credit等來計算進程的sleep_avg

（詳見"平均等待時間sleep_avg"一節(jié)），在最后調(diào)用effective_prio()來計算函數(shù)

的動態(tài)優(yōu)先級。總的來說，有以下幾種情況需要計算進程的優(yōu)先級：

a. 創(chuàng)建新進程，使用函數(shù)effective_prio()（因為此時進程尚未進行調(diào)度，沒有

sleep_avg和interactive_credit可言）；

b. 喚醒等待進程時，使用函數(shù)recalc_task_prio ()來計算進程動態(tài)優(yōu)先級。

c. 進程用完時間片以后，被重新插入到active array或者expired array的時候需要

重新計算動態(tài)優(yōu)先級，以便將進程插入到隊列的相應(yīng)位置。此時，使用函數(shù)

effective_prio()；

d. 其他情況，如IDLE進程初始化等時候。

2. 進程時間片

(1) 時間片的計算

進程的時間片time_slice是基于進程靜態(tài)優(yōu)先級的，靜態(tài)優(yōu)先級越高（值越小），時

間片就越大。計算時間片是同過函數(shù)task_timeslice()（kernel/sched.c）來完成的

。該函數(shù)也是使用線性映射的方法，將進程優(yōu)先級[MAX_RT_PRIO, MAX_PRIO-1]映射

到時間片[MIN_TIMESLICE, MAX_TIMESLICE]范圍內(nèi)。通過優(yōu)先級來計算時間片的等式

為：

timeslice = MIN_TIMESLICE + ((MAX_TIMESLICE - MIN_TIMESLICE) *

(MAX_PRIO-1- (p)->static_prio) / (MAX_USER_PRIO-1))

(2) 何時計算時間片

當就緒進程的所有進程的時間片都是0的時候，許多操作系統(tǒng)（包括舊版本的Linux）

是使用下面的循環(huán)來給進程隊列計算時間片的：

for (each task on the system) {

? ? ? ? recalculate priority;

? ? ? ? recalculate timeslice

}

這樣的循環(huán)計算會導(dǎo)致以下問題：

? ? ? ? 循環(huán)可能會花很長時間，而且算法的復(fù)雜度O(n)；

? ? ? ? 計算過程中必須給進程隊列和task_struct上鎖，這樣可能導(dǎo)致大量的競爭；

? ? ? ? 因為計算時間不可預(yù)計，所以可能給實時進程帶來問題；

在Kernel 2.6中時間片的計算是分散的，具體的計算既可以用task_timeslice()，也

可以用其他方法。

? ? ? ? a. 進程創(chuàng)建時，將父進程的時間片分一半給子進程，同時父進程的時間片減半。

（詳見"sched_fork"一節(jié)）；

? ? ? ? b. 進程用完時間片以后，需要重新計算時間片，并將進程插入到相應(yīng)的運行

隊列。（詳見"scheduler_tick"一節(jié)）；

? ? ? ? c. 進程退出時，根據(jù)first_timeslice的值來決定是否將子進程的時間片返

還給父進程。（詳見"退出調(diào)度"一節(jié)）。

可見Kernel2.6通過分散計算時間片的辦法很好解決了上面循環(huán)計算所帶來的幾個問題。

3. 平均等待時間sleep_avg

平均等待時間sleep_avg既決定了進程優(yōu)先級，又影響了進程交互程度的，因此它是

Kernel 2.6調(diào)度系統(tǒng)里面很復(fù)雜的一塊。下面將跟蹤調(diào)度器中sleep_avg的變化情況。

(1) 進程創(chuàng)建

當一個進程被創(chuàng)建的時候，父進程的sleep_avg要乘以"PARENT_PENALTY / 100"，子

進程的sleep_avg要乘以"CHILD_PENALTY / 100"，PARENT_PENALTY=100，而

CHILD_PENALTY = 95，可見創(chuàng)建以后子進程的sleep_avg要降低，而父進程則不變。

(2) 進程被喚醒

當一個進程被喚醒以后，acitvate_task()將調(diào)用函數(shù)recalc_task_prio()來計算進

程的sleep_avg，參數(shù)是進程的睡眠時間，從而進一步計算進程的動態(tài)優(yōu)先級。計算

sleep_avg有以下幾種可能（當然都需在0 ~ NS_MAX_SLEEP_AVG范圍內(nèi)）：

a. MAX_SLEEP_AVG - AVG_TIMESLICE

當用戶進程（p->mm）不是由UNINTERRUPTIBLE狀態(tài)喚醒（p->activated != -1），且

睡眠時間大于INTERACTIVE_SLEEP(p)，則做此賦值；

b. 不變

當用戶進程（p->mm）是由UNINTERRUPTIBLE狀態(tài)喚醒（p->activated == -1），且"

交互程度"不高（!HIGH_CREDIT(p)），如果原來的sleep_avg已經(jīng)大于INTERACTIVE_SLEEP

(p)，則不變（對非自愿睡眠的進程進行懲罰）；否則見下面一條；

c. INTERACTIVE_SLEEP(p)

如果加上此次的睡眠時間后大于INTERACTIVE_SLEEP(p)，則sleep_avg賦值為

INTERACTIVE_SLEEP(p)；

d. sleep_avg+sleep_time

如果以上條件全都不滿足，則直接將本次睡眠時間加到sleep_avg上。

(3) 進程調(diào)度過程中

在schedule()過程中，如果發(fā)現(xiàn)優(yōu)先級最高的程序是剛剛從TASK_INTERRUPTIBLE狀態(tài)

被喚醒的進程（actived>0，參見"actived"的定義），那么將調(diào)用recalc_task_prio

()，運算過程與(2)相同，所不同的就是調(diào)用時的參數(shù)sleep_time是進程在就緒隊列

的等待時間。如果進程不是被中斷喚醒的（actived=1），那么sleep_time還將受到

"(ON_RUNQUEUE_WEIGHT * 128 / 100) / 128"的限制，因為該進程很可能不是交互式

進程。

(4) 進程被剝奪CPU使用權(quán)

當進行進程切換的時候，被剝奪CPU使用權(quán)的進程的sleep_avg將會被減去進程的運行

時間run_time（這里的run_time對于交互式進程也有獎勵的，詳見"交互式進程優(yōu)先

"一節(jié)），從而保證調(diào)度器的公平性。進程運行的時間越長，sleep_avg就越小（底限

是0），進程的動態(tài)優(yōu)先級也就越低，從而被調(diào)度器調(diào)度到的機會也就會越小。

(5) 進程退出

當一個進程退出時，如果該進程的sleep_avg比父進程要小（也就是運行時間長），

那么父進程將得到懲罰。具體懲罰的規(guī)則為：

p->parent->sleep_avg = p->parent->sleep_avg / (EXIT_WEIGHT+1) * EXIT_WEIGHT

?+ p->sleep_avg / ?(EXIT_WEIGHT + 1);

父進程的sleep_avg將變?yōu)樵瓉淼?/( EXIT_WEIGHT+1)，再加上子進程的sleep_avg的

1/( EXIT_WEIGHT+1)，可見子進程運行的越多，父進程得到的懲罰也就越大。這樣也

是為了保證調(diào)度器的公正性。

4. 交互進程優(yōu)化

Kernel 2.6為了增加系統(tǒng)在高負載情況下的交互感受，做了以下三點優(yōu)化。

(1) interactive_credit -- 獎勵sleep_avg

interactive_credit是設(shè)置在task_struct里面用來標記進程的"交互程度"的，它在

進程創(chuàng)建時候被置為0，以后隨著不同的情況而增加，減少。

增加

interactive_credit有兩處增1的地方，都在函數(shù)recalc_task_prio()里面。

a. 進程所擁有的內(nèi)存區(qū)域不為空(p->mm!=NULL)，即進程不是內(nèi)核進程，如果不是從

?TASK_UNINTERRUPTIBLE狀態(tài)中被喚醒的（p->activated!=-1），且等待的時間（包

括在休眠中等待時間和在就緒隊列中等待時間）超過了一定限度（sleep_time>

INTERACTIVE_SLEEP(p)）；此時將interactive_credit增1；

b. 進程的等待時間大于NS_MAX_SLEEP_AVG了，這種進程很可能是交互進程，所以

interactive_credit增1。

減少

interactive_credit只有一處地方減1，在函數(shù)schedule()里面。當進程將要被切換

出CPU的時候，要計算進程的運行時間run_time，并將進程的sleep_avg進行調(diào)整，如

果調(diào)整后的sleep_avg小于0（說明進程的運行時間大于等待時間），而且該進程的

interactive_credit在HIGH_CREDIT(p)和LOW_CREDIT(p)之間（說明該進程非交互進程），

則將interactive_credit減1作為對進程的懲罰。

從上面的分析可以看出，無論interactive_credit如何增減，它都在-(CREDIT_LIMIT

+1) ~ (CREDIT_LIMIT+1)范圍內(nèi)；而且當interactive_credit增大到CREDIT_LIMIT+

1，即調(diào)度器認定該進程為交互進程以后，interactive_credit就不再變化。

調(diào)度器采用宏HIGH_CREDIT()來判斷一個進程是否是交互進程，如果是，則該進程將

得到以下獎勵：

a. 當進程被剝奪CPU使用權(quán)時，如果發(fā)現(xiàn)該進程是交互進程，則將該進程的運行時間

減小，run_time /= (CURRENT_BONUS(prev) ? : 1)。即sleep_avg減去的運行時間比

實際的運行時間要小，從而增加進程的sleep_avg。

b. 交互式進程在就緒隊列上等待的時間也將增加到sleep_avg里面，p->sleep_avg

+= sleep_time；從而增加進程的sleep_avg。

可見，對于交互進程都是獎勵sleep_avg的，從而達到提高優(yōu)先級的目的。對于交互

式進程，調(diào)度器并沒有在時間片上進行獎勵，而是在優(yōu)先級上進行獎勵，是因為交互

式進程通常是運行時間短、睡眠時間長，而且要求響應(yīng)快，而獎勵優(yōu)先級可以給交互

進程更多的運行機會，因此，調(diào)度器對于交互進程的獎勵辦法是非常公平和科學的。

(2) 平均等待時間sleep_avg -- 獎勵動態(tài)優(yōu)先級

在"平均等待時間"一節(jié)已做詳細介紹。對于交互進程來說，因為它睡眠的時間較長，

所以sleep_avg要大一些。另外，經(jīng)常處于TASK_INTERRUPTIBLE狀態(tài)，而且是被中斷

喚醒的進程最有可能是交互進程，而這種進程的衡量因素也是sleep_avg。

總之，由于交互進程一般sleep_avg較大，所以調(diào)度器通過獎勵動態(tài)優(yōu)先級的方式來

使得進程獲得更多執(zhí)行的機會。

?(3) TASK_INTERACTIVE() -- 獎勵再次被插入active array

這個宏是根據(jù)進程的動態(tài)優(yōu)先級和靜態(tài)優(yōu)先級來判斷該進程的"交互程度"。在進程時

間片用完時，使用這個宏作為一個參考因素來決定是否將進程重新插入active array

。它的定義是：

(p)->prio <= (p)->static_prio - DELTA(p)

DELTA(p) = ? ? ?(SCALE(TASK_NICE(p), 40, MAX_BONUS) + INTERACTIVE_DELTA)

SCALE(v1,v1_max,v2_max) = (v1) * (v2_max) / (v1_max)

可以看出這個宏是將進程的動態(tài)優(yōu)先級和進程的靜態(tài)優(yōu)先級做比較，以判斷nice值為

n（靜態(tài)優(yōu)先級）時，進程p需要多大的動態(tài)優(yōu)先級才能具有"足夠的交互性"。從宏的

定義可以看出當進程的nice值大于12時，進程是不可能被認為是具有足夠的交互性（

因為nice>12時，DELTA(p)>5，而由于sleep_avg給進程帶來的動態(tài)優(yōu)先級上的獎勵最

大只有5，所以TASK_INTERACTIVE(p)永假）；當進程的nice值為-20時，進程的sleep_avg

必須非常小才可能使得TASK_INTERACTIVE(p)值為假。

從以上分析可以看出，這三種獎勵辦法一個比一個獎勵力度大，獎勵條件也一個比一

個苛刻。而且調(diào)度器將用戶的意愿放在了第一位（因為nice值是可以通過系統(tǒng)調(diào)用改

變的），由于用戶的意愿而給予的獎勵（再次被插入active array）最大，而調(diào)度器

所給予的獎勵占的比例并不大。

? ? 19) 進程調(diào)度的核心數(shù)據(jù)結(jié)構(gòu)是哪個？

1 進程的優(yōu)先級

每個普通進程都有它自己的靜態(tài)優(yōu)先級，位于task_struct的static_prio字段，調(diào)度程序使用靜態(tài)優(yōu)先級來估價系統(tǒng)中這個進程與其它普通進程之間調(diào)度強度。但是，注意，調(diào)度程序不是根據(jù)靜態(tài)優(yōu)先級來決定調(diào)度哪個進程的，而是動態(tài)優(yōu)先級，后面會詳細談到。內(nèi)核用100（最高優(yōu)先級）到 139（最低優(yōu)先級）的整數(shù)表示普通進程的靜態(tài)優(yōu)先級。注意，值越大靜態(tài)優(yōu)先級就越低。

新進程總是繼承其父進程的靜態(tài)優(yōu)先級。不過，通過系統(tǒng)調(diào)用nice()和setprioritry()，用戶可以改變自己擁有的進程的靜態(tài)優(yōu)先級。

進程靜態(tài)優(yōu)先級本質(zhì)上決定了進程的基本時間片，即進程用完了以前的時間片，系統(tǒng)分配給進程的時間片長度。靜態(tài)優(yōu)先級和基本時間片的關(guān)系用下列公式確定：

進程的基本時間片實現(xiàn)函數(shù)為task_timeslice：

static inline unsigned int task_timeslice(struct task_struct *p)

{

return static_prio_timeslice(p->static_prio);

}

static unsigned int static_prio_timeslice(int static_prio)

{

if (static_prio < NICE_TO_PRIO(0)) //靜態(tài)優(yōu)先級小于120

return SCALE_PRIO(DEF_TIMESLICE * 4, static_prio); //(140-static_prio)*20

else

return SCALE_PRIO(DEF_TIMESLICE, static_prio);//(140-static_prio)*5

}

#define NICE_TO_PRIO(nice) ? ?(MAX_RT_PRIO + (nice) + 20)

#define MAX_USER_RT_PRIO ? ?100

#define MAX_RT_PRIO ? ? ? ?MAX_USER_RT_PRIO

我們看到，靜態(tài)優(yōu)先級越高，其基本時間片就越長。最后的結(jié)果是，與優(yōu)先級低的進程相比，通常優(yōu)先級較高的進程獲得更長的CPU時間片。

普通進程除了靜態(tài)優(yōu)先級，還有動態(tài)優(yōu)先級，其值的范圍也是是100（最高優(yōu)先級MAX_RT_PRIO，低于100就成了實時進程了）到139（最低優(yōu)先級MAX_PRIO）。動態(tài)優(yōu)先級是調(diào)度程序選擇新進程來運行的時候使用的數(shù)。它與靜態(tài)優(yōu)先級的關(guān)系用下面的所謂經(jīng)驗公式（empirical formula）表示：

動態(tài)優(yōu)先級 = max (100, min (靜態(tài)優(yōu)先級 - bonus + 5, 139)) ? (2)

動態(tài)優(yōu)先級的計算主要由 effect_prio() 函數(shù)完成，該函數(shù)實現(xiàn)相當簡單，從中可見非實時進程的優(yōu)先級僅決定于靜態(tài)優(yōu)先級（static_prio）和進程的平均睡眠時間（sleep_avg）兩個因素，而實時進程的優(yōu)先級實際上是在sched_setscheduler() 中設(shè)置的（詳見"實時進程調(diào)度系統(tǒng)"博文，以下僅考慮非實時進程），且一經(jīng)設(shè)定就不再改變。

動態(tài)優(yōu)先級的計算函數(shù)是effective_prio，函數(shù)effective_prio()讀current的static_prio和sleep_avg字段，并根據(jù)前面的公式計算出進程的動態(tài)優(yōu)先級：

static int effective_prio(struct task_struct *p)

{

p->normal_prio = normal_prio(p);//首先計算出普通進程的優(yōu)先級，存放在task_struct的normal_prio字段

if (!rt_prio(p->prio))

return p->normal_prio;

return p->prio; //如果是實時進程，優(yōu)先級不變

}

static inline int normal_prio(struct task_struct *p)

{

int prio;

if (has_rt_policy(p))

prio = MAX_RT_PRIO-1 - p->rt_priority;

else

prio = __normal_prio(p);

return prio;

}

#define rt_prio(prio) ? ? ? ?unlikely((prio) < MAX_RT_PRIO) //prio小于100就是實時進程

static inline int __normal_prio(struct task_struct *p)

{//執(zhí)行該函數(shù)的前提是非實時進程

int bonus, prio;

bonus = CURRENT_BONUS(p) - MAX_BONUS / 2;

prio = p->static_prio - bonus;

if (prio < MAX_RT_PRIO) ?// MAX_RT_PRIO的值為100

prio = MAX_RT_PRIO; ?// 不能讓你普通進程的優(yōu)先級高于實時進程

if (prio > MAX_PRIO-1) ? // MAX_PRIO的值為140

prio = MAX_PRIO-1; ? // 不能超過最大優(yōu)先級139

return prio;

}

動態(tài)優(yōu)先級算法的實現(xiàn)關(guān)鍵在 sleep_avg 變量上，在effective_prio() 中，sleep_avg 的范圍是 0~MAX_SLEEP_AVG，經(jīng)過以下公式轉(zhuǎn)換后變成-MAX_BONUS/2~MAX_BONUS/2 之間的 bonus：

bonus = (NS_TO_JIFFIES((p)->sleep_avg) * MAX_BONUS / MAX_SLEEP_AVG) - MAX_BONUS/2

#define MAX_BONUS ? ? ? ?(MAX_USER_PRIO * PRIO_BONUS_RATIO / 100)

#define MAX_USER_PRIO ? ? ? ?(USER_PRIO(MAX_PRIO))

#define USER_PRIO(p) ? ? ? ?((p) - MAX_RT_PRIO)

#define MAX_RT_PRIO ? ? ? ?MAX_USER_RT_PRIO

#define MAX_USER_RT_PRIO ? ?100

.........弄得那么復(fù)雜，其實MAX_BONUS是定值10，MAX_SLEEP_AVG也是定值：

#define MAX_SLEEP_AVG ? ? ? ?(DEF_TIMESLICE * MAX_BONUS)

#define DEF_TIMESLICE ? ? ? ?(100 * HZ / 1000)

#define CURRENT_BONUS(p) (NS_TO_JIFFIES((p)->sleep_avg) * MAX_BONUS / MAX_SLEEP_AVG)

#define NS_TO_JIFFIES(TIME) ? ?((TIME) / (1000000000 / HZ))

所以bonus與平均睡眠時間sleep_avg成正比。不管怎么說，sleep_avg 反映了調(diào)度系統(tǒng)的兩個策略：交互式進程優(yōu)先和分時系統(tǒng)的公平共享。

bonus（獎賞）是從范圍0~10的值，值小于5表示降低動態(tài)優(yōu)先級以懲戒，值大于5表示增加動態(tài)優(yōu)先級以使獎賞。bonus的值依賴于進程的過去情況，與進程的平均睡眠時間有關(guān)，也就是說，平均睡眠時間越久，bonus值越大。

那么，什么是平均睡眠時間呢？粗略地講，平均睡眠時間就是進程在睡眠狀態(tài)中所消耗的平均納秒數(shù)，其存放在task_struck的sleep_avg字段中。注意，這絕對不是對過去時間的求平均值操作，因為TASK_INTERRUPTIBLE 狀態(tài)和TASK_UNINTERRUPTIBLE狀態(tài)所計算出的平均睡眠時間是不同的，而且，進程在運行的過程中平均睡眠時間遞減。最后，平均睡眠時間永遠不會大于1s。

根據(jù)CURRENT_BONUS宏，我們可以得到bonus和sleep_avg的對應(yīng)關(guān)系：

平均睡眠時間sleep_avg?

?bonus?

?粒度?

大于或等于 0 小于 100 ms?

?5120

大于或等于100 小于200 ms?

?2560

大于或等于200 小于300 ms?

?1280

大于或等于300 小于 400 ms?

?640

大于或等于400 小于 500 ms?

?320

大于或等于500 小于 600 ms?

?160

大于或等于600 小于 700 ms?

?80

大于或等于700 小于 800 ms?

?40

大于或等于800 小于 900 ms?

?20

大于或等于900 小于 1000 ms?

?10

1 秒?

?10

平均睡眠時間也被調(diào)度程序用來評判一個給定進程是交互式進程還是批處理進程的依據(jù) 。如果一個進程滿足：

動態(tài)優(yōu)先級 ≤ 3 × ?靜態(tài)優(yōu)先級/4 + 28 ? ? ? (3)

那么就看做是交互式進程。高優(yōu)先級進程比低優(yōu)先級進程更容易成為交互式進程。例如，具有最高靜態(tài)優(yōu)先級（100）的進程，當他的bonus值超過2，即睡眠超過200ms時，就被看做是交互式進程。判斷交互式進程代碼的具體實現(xiàn)請參看博文“recalc_task_prio函數(shù) ”。

下面再介紹一些內(nèi)核調(diào)用effective_prio給進程計算優(yōu)先級的時機（計一般在進程狀態(tài)發(fā)生改變，內(nèi)核就有可能計算并設(shè)置進程的動態(tài)優(yōu)先級）：

a) 創(chuàng)建進程

在copy_process()中，子進程繼承了父進程的動態(tài)優(yōu)先級，平分父進程的時間片，并添加到父進程所在的就緒隊列中。如果父進程不在任何就緒隊列中（例如它是 IDLE 進程），那么就通過effective_prio() 函數(shù)計算出子進程的優(yōu)先級，而后根據(jù)計算結(jié)果將子進程放置

到相應(yīng)的就緒隊列中。

b) 喚醒休眠進程

核心調(diào)用 recalc_task_prio() 設(shè)置從休眠狀態(tài)中醒來的進程的動態(tài)優(yōu)先級，再根據(jù)優(yōu)先級放置到相應(yīng)就緒隊列中。

c) 調(diào)度到從 TASK_INTERRUPTIBLE 狀態(tài)中被喚醒的進程

實際上此時調(diào)度器已經(jīng)選定了候選進程，但考慮到這一類型的進程很有可能是交互式進程，因此此時仍然調(diào)用 recalc_task_prio() 對該進程的優(yōu)先級進行修正，修正的結(jié)果將在下一次調(diào)度時體現(xiàn)。

d) 進程因時間片相關(guān)的原因被剝奪 cpu

在 schedule_tick() 中（由定時器中斷啟動），進程可能因兩種原因被剝奪 cpu，一是時間片耗盡，一是因時間片過長而分段。這兩種情況都會調(diào)用effective_prio() 重新計算優(yōu)先級，重新入隊。?

e) 其它時機

這些其它時機包括IDLE 進程初始化（init_idle()）、負載平衡以及修改 nice 值（set_user_nice()）、修改調(diào)度策略等主動要求改變優(yōu)先級的情況。

即使具有較高靜態(tài)優(yōu)先級的普通進程獲得較大的CPU時間片，也不應(yīng)該使靜態(tài)優(yōu)先級較低的進程無法運行。為了避免饑餓，當一個進程用完它的時間片時，它應(yīng)該被還沒有用完時間片的低優(yōu)先級的進程取代。為了實現(xiàn)這種機制，調(diào)度程序維持兩個不相交的可運行進程集合：活動進程和過期進程。太復(fù)雜了是不？別著急，我們還是從數(shù)據(jù)結(jié)構(gòu)入手。

2 數(shù)據(jù)結(jié)構(gòu)

回憶一下前面講的，系統(tǒng)中有個0號進程的task_struct結(jié)構(gòu)init_task，然后以它打頭，系統(tǒng)中每個進程的tasks字段鏈接在一起形成一個雙向循環(huán)鏈表表。另外，每個CPU有個運行進程鏈表runqueue（2.6.18內(nèi)核以后叫做rq，存放在位于kernel/Sched.c中），稱為運行隊列。作為Linux2.6調(diào)度程序最重要的數(shù)據(jù)結(jié)構(gòu)，runqueue數(shù)據(jù)結(jié)構(gòu)存放在runqueues每個CPU變量中，宏this_rq() 產(chǎn)生本地CPU運行隊列的地址，而宏cpu_rq(n)產(chǎn)生索引為n的CPU運行隊列地址。

struct runqueue {

spinlock_t lock;

unsigned long nr_running;

#ifdef CONFIG_SMP

unsigned long cpu_load;

#endif

unsigned long long nr_switches;

unsigned long nr_uninterruptible;

unsigned long expired_timestamp;

unsigned long long timestamp_last_tick;

task_t *curr, *idle;

struct mm_struct *prev_mm;

prio_array_t *active, *expired, arrays[2];

int best_expired_prio;

atomic_t nr_iowait;

#ifdef CONFIG_SMP

struct sched_domain *sd;

/* For active balancing */

int active_balance;

int push_cpu;

task_t *migration_thread;

struct list_head migration_queue;

#endif

};

runqueue數(shù)據(jù)結(jié)構(gòu)中最重要的字段是與可運行進程的鏈表相關(guān)的字段。系統(tǒng)中的每個可運行進程屬于且只屬于一個運行隊列。只要可運行進程保持在同一個運行隊列中，它就只可能在擁有該運行隊列的CPU上執(zhí)行。

運行隊列arrays字段是一個包含兩個prio_array_t結(jié)構(gòu)的數(shù)組。每個數(shù)據(jù)結(jié)構(gòu)都表示一個可運行進程的集合，并包括140個雙向鏈表頭（每個鏈表對應(yīng)一個可能的進程優(yōu)先級）、一個優(yōu)先級位圖和一個集合中所包含的進程數(shù)量的計數(shù)器：

struct prio_array {

unsigned int nr_active;

unsigned long bitmap[BITMAP_SIZE];

struct list_head queue[MAX_PRIO];

};

下圖可以看到，runqueue結(jié)構(gòu)的active字段指向arrays中的兩個prio_array_t數(shù)據(jù)結(jié)構(gòu)之一：對應(yīng)于包含活動進程的可運行進程的集合。相反，expired字段指向數(shù)組中的另一個prio_array_t數(shù)據(jù)結(jié)構(gòu)：對應(yīng)于包含過去進程的可運行進程的集合。

下面簡單說一下rq結(jié)構(gòu)中的其他字段的用處：

spinlock_t lock：runqueue 的自旋鎖，當需要對 runqueue 進行操作時，仍然應(yīng)該鎖定，但這個鎖定操作只影響一個 CPU 上的就緒隊列，因此，競爭發(fā)生的概率要小多了。

task_t *curr：本 CPU 正在運行的進程。

tast_t *idle：指向本 CPU 的 idle 進程，表示本地CPU的swapper進程，相當于 2.4 中 init_tasks[this_cpu()] 的作用。

int best_expired_prio：記錄 expired 就緒進程組中的最高優(yōu)先級（數(shù)值最小）。該變量在進程進入expired 隊列的時候保存（schedule_tick()），用途見下面expired_timestamp的解釋）。

unsigned long expired_timestamp：當新一輪的時間片遞減開始后，這一變量記錄著最早發(fā)生的進程耗完時間片事件的時間（jiffies 的絕對值，在 schedule_tick() 中賦），它用來表征expired 中就緒進程的最長等待時間。它的使用體現(xiàn)在 EXPIRED_STARVING(rq)宏上。

上面已經(jīng)提到，每個 CPU 上維護了兩個就緒隊列，active 和 expired。一般情況下，時間片結(jié)束的進程應(yīng)該從 active 隊列轉(zhuǎn)移到 expired 隊列中（schedule_tick()），但如果該進程是交互式進程（實時進程FIFO或RR），調(diào)度器就會讓其保持在active 隊列上以提高它的響應(yīng)速度。這種措施不應(yīng)該讓其他就緒進程等待過長時間，也就是說，如果 expired 隊列中的進程已經(jīng)等待了足夠長時間了，即使是交互式進程也應(yīng)該轉(zhuǎn)移到 expired 隊列上來，排空 active。這個閥值就體現(xiàn)在EXPIRED_STARVING(rq) 上：在 expired_timestamp 和 STARVATION_LIMIT都不等于 0 的前提下，如果以下兩個條件都滿足，則 EXPIRED_STARVING() 返回真：

·（當前絕對時間 - expired_timestamp） >= （STARVATION_LIMIT * 隊列中所有就緒進程總數(shù) + 1），也就是說 expired 隊列中至少有一個進程已經(jīng)等待了足夠長的時間；

·正在運行的進程的靜態(tài)優(yōu)先級比 expired 隊列中最高優(yōu)先級要低（best_expired_prio，數(shù)值要大），此時當然應(yīng)該盡快排空 active 切

換到expired 上來。

struct mm_struct *prev_mm：保存進程切換后被調(diào)度下來的進程（稱之為 prev）的 active_mm 結(jié)構(gòu)指針。因為在 2.6 中 prev 的 active_mm 是在進程切換完成之后釋放的（mmdrop()），而此時 prev 的 active_mm 項可能為 NULL，所以有必要在runqueue 中預(yù)先保留。

unsigned long nr_running：本 CPU 上的就緒進程數(shù)，該數(shù)值是 active 和 expired 兩個隊列中進程數(shù)的總和，是說明本 CPU 負載情況的重要參數(shù)（詳見"調(diào)度器相關(guān)的負載平衡 "）。

unsigned long nr_switches：記錄了本 CPU 上自調(diào)度器運行以來發(fā)生的進程切換的次數(shù)。

unsigned long nr_uninterruptible：記錄本 CPU 尚處于 TASK_UNINTERRUPTIBLE 狀態(tài)的進程數(shù)，和負載信息有關(guān)。

atomic_t nr_iowait：記錄本 CPU 因等待 IO 而處于休眠狀態(tài)的進程數(shù)。

unsigned long timestamp_last_tick：本就緒隊列最近一次發(fā)生調(diào)度事件的時間，在負載平衡的時候會用到（見"調(diào)度器相關(guān)的負載平衡 "）。

task_t *migration_thread：指向本 CPU 的遷移進程。每個 CPU 都有一個核心線程用于執(zhí)行進程遷移操作（見"調(diào)度器相關(guān)的負載平衡 "）。

struct list_head migration_queue：需要進行遷移的進程列表（見"調(diào)度器相關(guān)的負載平衡 "）。

arrays中的兩個prio_array_t數(shù)據(jù)結(jié)構(gòu)的作用會發(fā)生周期性的變化：活動進程突然變成過期進程，而過期進程變化為活動進程，調(diào)度程序簡單地交互運行隊列的active和expired字段的內(nèi)容以完成這種變化。每個進程描述符task_struct都包括幾個與調(diào)度相關(guān)的字段：

1) state

進程的狀態(tài)仍然用 state 表示，不同的是，2.6 里的狀態(tài)常量重新定義了，以方便位操作：

/* 節(jié)選自[include/linux/sched.h] */

#define TASK_RUNNING 0

#define TASK_INTERRUPTIBLE 1

#define TASK_UNINTERRUPTIBLE 2

#define TASK_STOPPED 4

#define TASK_ZOMBIE 8

#define TASK_DEAD 16

新增加的TASK_DEAD 指的是已經(jīng)退出且不需要父進程來回收的進程。

2) timestamp

進程發(fā)生調(diào)度事件的時間點、時間戳（單位是：納秒 —— nanosecond，見下）。包括以下幾類：

· 被喚醒的時間（在 activate_task() 中設(shè)置）；

· 被切換下來的時間（schedule()）；

· 被切換上去的時間（schedule()）；

· 負載平衡相關(guān)的賦值（見"調(diào)度器相關(guān)的負載平衡"）。

從這個值與當前時間的差值中可以分別獲得"在就緒隊列中等待運行的時長"、"運行時長"等與優(yōu)先級計算相關(guān)的信息（見"優(yōu)化了的優(yōu)先級計算方法"）。

兩種時間單位：系統(tǒng)的時間是以 nanosecond（十億分之一秒）為單位的，但這一數(shù)值粒度過細，大部分核心應(yīng)用僅能取得它的絕對值，感知不到它的精度。時間相關(guān)的核心應(yīng)用通常圍繞時鐘中斷進行，在 Linux 2.6 中，系統(tǒng)時鐘每1 毫秒中斷一次（時鐘頻率，用 HZ 宏表示，定義為 1000，即每秒中斷 1000次），這個時間單位稱為一個 jiffie。很多核心應(yīng)用都是以 jiffies 作為時間單位，例如進程的運行時間片。

jiffies 與絕對時間之間的轉(zhuǎn)換公式如下：

nanosecond=jiffies*1000000

核心用兩個宏來完成兩種時間單位的互換：JIFFIES_TO_NS()、NS_TO_JIFFIES()，很多時間宏也有兩種形式，例如 NS_MAX_SLEEP_AVG 和

MAX_SLEEP_AVG。

3) prio

優(yōu)先級，在 0~MAX_PRIO-1 之間取值（MAX_PRIO 定義為 140），其中 0~MAX_RT_PRIO-1 （MAX_RT_PRIO 定義為100）屬于實時進程范圍，MAX_RT_PRIO~MX_PRIO-1 屬于非實時進程。數(shù)值越大，表示進程優(yōu)先級越小。2.6 中，動態(tài)優(yōu)先級不再統(tǒng)一在調(diào)度器中計算和比較，而是獨立計算，并存儲在進程的 task_struct 中，再通過上面描述的 priority_array 結(jié)構(gòu)自動排序。

4) static_prio

nice 值沿用 Linux 的傳統(tǒng)，在 -20 到 19 之間變動，數(shù)值越大，進程的優(yōu)先級越小。nice 是用戶可維護的，但僅影響非實時進程的優(yōu)先級。2.6 內(nèi)核中不再存儲 nice 值，而代之以 static_prio：static_prio = MAX_RT_PRIO + nice + 20（MAX_RT_PRIO=100）。進程初始時間片的大小僅取決于進程的靜態(tài)優(yōu)先級，這一點不論是實時進程還是非實時進程都一樣，不過實時進程的 static_prio 不參與優(yōu)先級計算。?

5) activated

表示進程因什么原因進入就緒態(tài)，這一原因會影響到調(diào)度優(yōu)先級的計算。activated 有四個值：

· -1，進程從 TASK_UNINTERRUPTIBLE 狀態(tài)被喚醒；

· 0，缺省值，進程原本就處于就緒態(tài)；

· 1，進程從 TASK_INTERRUPTIBLE 狀態(tài)被喚醒，且不在中斷上下文中；

· 2，進程從 TASK_INTERRUPTIBLE 狀態(tài)被喚醒，且在中斷上下文中。

activated 初值為 0，在兩個地方修改，一是在 schedule() 中，被恢復(fù)為 0，另一個就是 activate_task()，這個函數(shù)由 try_to_wake_up()

函數(shù)調(diào)用，用于激活休眠進程：

· 如果是中斷服務(wù)程序調(diào)用的 activate_task()，也就是說進程由中斷激活，則該進程最有可能是交互式的，因此，置 activated=2；否則置

activated=1。

· 如果進程是從 TASK_UNINTERRUPTIBLE 狀態(tài)中被喚醒的，則activated=-1（在try_to_wake_up()函數(shù)中）。

6) sleep_avg

進程的平均等待時間（以 nanosecond 為單位），在 0 到 NS_MAX_SLEEP_AVG之間取值，初值為 0，相當于進程等待時間與運行時間的差值。sleep_avg 所代表的含義比較豐富，既可用于評價該進程的"交互程度"，又可用于表示該進程需要運行的緊迫性。這個值是動態(tài)優(yōu)先級計算的關(guān)鍵因子，sleep_avg 越大，計算出來的進程優(yōu)先級也越高（數(shù)值越小）。在博文"recalc_task_prio函數(shù) " 中會詳細分析 sleep_avg 的變化過程。

7) policy：進程的調(diào)度類型（SCHED_NORMAL, SCHED_RR, 或 SCHED_FIFO）

8) thread_info->flags：存放TIF_NEED_RESCHED 標志，如果必須調(diào)用調(diào)度程序，則設(shè)置該標志

9) thread_info->cpu：可運行進程所在運行隊列的CPU邏輯號

10) run_list：指向進程所屬的運行隊列鏈表中的下一個和前一個元素

12) array：指向包含進程運行隊列的集合prio_array_t

13) last_ran：最近一次替換本進程的進程切換時間

14) cpus_allowed：能執(zhí)行進程的CPU的位掩碼

15) time_slice：在進程的時間片中還剩余的時鐘節(jié)拍數(shù)

16) first_time_slice：如果進程肯定不會用完其時間片，就把該標志設(shè)置為1

17) rt_priority：進程的實時優(yōu)先級

所有state處于TASK_RUNNING狀態(tài)的進程，則在運行隊列鏈表中以run_list組成以prio_array[prio]打頭的一個進程循環(huán)鏈表。

當新進程被創(chuàng)建的時候，由copy_process()調(diào)用的函數(shù)sched_fork()用下述方法設(shè)置current進程（父進程）和p進程（子進程）的time_slice字段：

p->time_slice = (current->time_slice + 1) >> 1;

current->time_slice >>= 1;

由此可以看出，父進程剩余的節(jié)拍數(shù)被劃分成兩等分，一份給父進程，另一份給子進程。如果父進程的時間片只剩下一個時鐘節(jié)拍，則劃分操作強行把 current->time_slice重新置為1，然后調(diào)用scheduler_tick()遞減該字段，從而使 current->time_slice變?yōu)?，耗盡父進程的時間片，把父進程移入expired中。

函數(shù)copy_process()也初始化子進程描述符中與進程調(diào)度相關(guān)的幾個字段：

p->first_time_slice = 1;

p->timestamp = sched_clock( );

因為子進程沒有用完它的時間片（如果一個進程在它的第一個時間片內(nèi)終止或執(zhí)行新的程序，就把子進程的剩余時間獎勵給父進程），所以 first_time_slice標志置為1.用函數(shù)sched_clock()所產(chǎn)生的時間戳的值初始化timestamp字段：函數(shù) sched_clock返回被轉(zhuǎn)化成納秒的64位寄存器TSC的內(nèi)容。

3 調(diào)度程序所使用的函數(shù)

調(diào)度程序基本依靠下面幾個函數(shù)來完成調(diào)度工作：

scheduler_tick( )：維持當前最新的time_slice計數(shù)器。

try_to_wake_up( )：喚醒睡眠進程。

recalc_task_prio( )：更新進程的動態(tài)優(yōu)先級。

schedule( )：選擇要被執(zhí)行的新進程。

? ? ?20) 如何加載、卸載一個模塊？

一、什么是 modules？

modules 的字面意思就是模塊，在此指的是 kernel modules；簡單來說，一個模塊提供了一個功能，如 isofs、minix、nfs、lp 等等。傳統(tǒng)來講，模塊化有兩個方法解決：設(shè)計者可以把各項功能分離到單獨的叫做線程的處理中去，或者是將內(nèi)核以包含/排除一些功能的方式重新編譯。如果把功能分離到線程中去，那么內(nèi)核就叫做“微內(nèi)核”(micro-kernel)，這種解決方法增加了線程間協(xié)調(diào)工作的通信開銷。就象名字暗示的那樣，這種解決方案的優(yōu)點在于內(nèi)核的大小。

linux的解決方案是包含內(nèi)核模塊，這些模塊是可以按需要隨時裝入和卸下的。這樣做可以使得內(nèi)核的大小和通信量都達到最小。將模塊從內(nèi)核中獨立出來，不必預(yù)先『綁』在kernel codes 中。這樣做有三種優(yōu)點：第一，將來修改 kernel 時，不必全部重新compile，可節(jié)省不少時間；第二，若需要安裝新的 modules ，不必重新 compile kernel，只要插入(通過insmode指令) 對應(yīng)的 modules 即可；第三，減少內(nèi)核對系統(tǒng)資源的占用，內(nèi)核可以集中精力做最基本的事情，把一些擴展功能都交由modules實現(xiàn)。

模塊也可以用來嘗試新的內(nèi)核代碼而不需要每次都創(chuàng)建和重激活內(nèi)核。但是，這樣做帶來的問題是：使用內(nèi)核模塊通常會輕微的增加性能和內(nèi)存開支。一個可加載模塊肯定會產(chǎn)生更多的代碼，這種代碼和額外的數(shù)據(jù)結(jié)構(gòu)會占用更多一點的內(nèi)存。另外因為間接訪問內(nèi)核資源也讓模塊的效率輕微降低。

模塊化的思想已經(jīng)被廣泛接受，主要的原因在于它可以擴展系統(tǒng)的功能，用戶可以靈活的配置系統(tǒng)。Apache也采取了這種功能擴展方式，在本文中主要討論是內(nèi)核的模塊安裝與卸載，Apache模塊的安裝請參照Apapce的相關(guān)文檔。

二、如何加載模塊？

加載內(nèi)核模塊的方法有兩種。第一種使用insmod命令手工把它插入到內(nèi)核。另一個更智能的方法是在需要的時候加載這個模塊︰這叫做按需加載（demand loading）。當內(nèi)核發(fā)現(xiàn)需要一個模塊的時候，例如當用戶安裝一個不在內(nèi)核的文件系統(tǒng)的時候，內(nèi)核會請求內(nèi)核守護進程（kerneld）試圖加載合適的模塊。說到這里就不能不提到內(nèi)核守護進程kerneld了，它非常的聰明，能夠主動的把您需要的modules 自動插入 kernel，將沒用到的 module 從kernel中清退。Kerneld由兩個獨立的部分構(gòu)成：一部分工作于linux的內(nèi)核，負責向daemon發(fā)送請求；另一部分工作于系統(tǒng)的用戶數(shù)據(jù)區(qū)，負責調(diào)入由內(nèi)核請求指定的modules。若少了這個kerneld，就只能通過手工的方式,用insmode或modeprobe命令進行加載。

三、modules的相關(guān)命令介紹

與modules有關(guān)的命令有：

lsmod : 列出已經(jīng)被內(nèi)核調(diào)入的模塊?

insmod : 將某個module插入到內(nèi)核中?

rmmod ：將某個module從內(nèi)核中卸載?

modprobe：自動根據(jù)依賴文件裝入模塊?

depmod : 生成依賴文件，告訴modprobe和kerneld要從哪兒調(diào)入modules。這個依賴文件就在/lib/modules/kernel版本/modules.dep。?

Kerneld：負責自動的將模塊調(diào)入內(nèi)核和把模塊從內(nèi)核中卸載。?

四、編譯一個最小的linux內(nèi)核

模塊一般用來支持那些不經(jīng)常使用的功能。例如，通常情況下你僅使用撥號網(wǎng)絡(luò)，因此網(wǎng)絡(luò)功能并不是任何時候都需要的，那么就應(yīng)該使用可裝入的模塊來提供這個功能。僅在你進行撥號聯(lián)接的時候，該模塊才被裝入。而在你斷掉連接的時候它會被自動卸下。這樣會使內(nèi)核使用內(nèi)存的量最小，減小系統(tǒng)的負荷。

當然，那些象硬盤訪問這樣時時刻刻都需要的功能，則必須作在內(nèi)核里。如果你搭一臺網(wǎng)絡(luò)工作站或web服務(wù)器，那么網(wǎng)絡(luò)功能是時刻都需要的，你就應(yīng)該考慮把網(wǎng)絡(luò)功能編譯到內(nèi)核里。另外一個方法是在啟動的時候就裝入網(wǎng)絡(luò)模塊。這種方法的優(yōu)點是你不需要重新編譯內(nèi)核。而缺點是網(wǎng)絡(luò)功能不能特別高效。

按照以上的原則，我們首先列出一張清單，看看 kernel 中哪些選項是非有不可的，也就是說，這些東西是必須被編譯到內(nèi)核中的。將那些非必需的模塊剔除到內(nèi)核以外。

第一個是root所在的硬盤配置。如果您的硬盤是IDE接口，就把 ide 的選項標記下來。如果是SCSI接口，請把您的接口參數(shù)及 SCSI id 記標下來。

第二個是選擇使用哪一個文件系統(tǒng)。linux的默認文件系統(tǒng)是是 ext2 ，那么就一定要把它標記下來。如果機器中還其它的操作系統(tǒng)，如win98或windows NT，您還會可能選擇FAT32或NTFS的支持，不過后面你可以通過手工加載的方式來加入新的模塊支持。

第三個是選擇linux所支持的可執(zhí)行文件格式。這里有兩種格式可供選擇：1、elf：這是當前l(fā)inux普遍支持的可執(zhí)行文件格式，必須編譯到內(nèi)核中。2、a.out：這是舊版的linux的可執(zhí)行文件各函數(shù)庫的格式，如果你確認肯定用不到這種格式的可執(zhí)行文件，那么就可以不把它編譯到內(nèi)核當中。

以上這些內(nèi)容，是必須要編譯到內(nèi)核中的。其它的內(nèi)容凡是所有選項中m提示的，都選擇m，這樣可以通過手工的方式添加該模塊。

** Loadable module support**

Enable loadable module support (CONFIG_MODULES) [Y/n/?]

Set versioninformation on all symbols for modules (CONFIG_MODVERSIONS) [N/y/?]

Kernel daemon support (e.g.autoload of modules) (CONFIG_KERNELD) [Y/n/?]

分別回答 Y,N,Y 。其中 CONFIG_KERNELD 的 default 值是 N，所以要注意選擇Y。

make config 完后，仍舊是 make dep; make clean。接下來要 make zlilo 或 make zImage。然后 make modules ; make modules_install 。完成之后，就編譯出一個沒有調(diào)入多余模塊的一個“干凈的”內(nèi)核映像文件了。

五、如何手工加載Modules？

如果要以手工的方式加載模塊, 建議最好使用 modprobe, 因為它可以解決模塊之間的依賴性問題，以聲卡的部分來說，以sound blaster 為例其總共有以下模塊：

sb 33652 0 (autoclean)

uart401 6160 0 (autoclean) [sb]

sound 56492 0 (autoclean) [sb uart401]

soundcore 2372 5 (autoclean) [sb sound]

這些模塊都要加載上來，整個聲卡才能工作，而且它們之間是有依賴性關(guān)系的。最核心的soundcore必須首先裝入, 最后裝入sb。但一般人是不知道其先后順序的。因此， modprobe就是用來解決這個問題用的。

通常我們只要"modprobe sb"它就會自動的找出 sb 用到的所有的模塊, 將它們一一的加載進來，故一般使用者就不用去傷腦筋了。

那么內(nèi)核是怎么知道這些模塊間的依賴性關(guān)系的呢？原來，在系統(tǒng)啟動腳本里有一條'depmod -a'命令，會給系統(tǒng)中的所有可用的模塊創(chuàng)建一個依賴關(guān)系的列表。而'modprobe module-name'會使用這個列表，在裝入指定的模塊前先裝入那些事先裝入的模塊。如果在這個從屬列表中找不到'module-name'的話，它會給出相應(yīng)的出錯信息。

但若使用 insmod, 它可不會自動完成其它模塊的調(diào)入。比如說，我們要加入PPP模塊，用這個命令：

root/root>insmod ppp

root/root>

如果操作成功，系統(tǒng)出現(xiàn)操作提示符。如果沒有成功，可能出現(xiàn)下列信息：

/lib/modules/2.2.10/net/ppp.o: unresolved symbol slhc_init_Rsmp_1ca65fca

/lib/modules/2.2.10/net/ppp.o: unresolved symbol slhc_compress_Rsmp_cfd3a418

/lib/modules/2.2.10/net/ppp.o: unresolved symbol slhc_free_Rsmp_b99033d9

/lib/modules/2.2.10/net/ppp.o: unresolved symbol slhc_toss_Rsmp_a152cec0

/lib/modules/2.2.10/net/ppp.o: unresolved symbol slhc_remember_Rsmp_07972313

/lib/modules/2.2.10/net/ppp.o: unresolved symbol slhc_uncompress_Rsmp_3bb36b01

[root /root]#

這說明，PPP模塊沒有加載成功，錯誤提示中的unresolved symbol說明， PPP模塊所需要的一些模塊還沒有載入。錯誤提示第一行的內(nèi)容是：slhc_init_Rsmp_1ca65fca ，這是哪個模塊？這其中可能需要一些經(jīng)驗來做判斷，它是以slhc開頭的，就試試slhc吧。

root/root>insmod slhc 一切正常，然后我們再加載PPP模塊

root/root>insmod ppp

root/root>

這回沒有什么返回信息，說明PPP模塊加載成功了。

六、從內(nèi)存中卸載一個Modules

要卸載一個模塊，首先用lsmod看看該模塊是否確實已經(jīng)加載上來，然后再做操作。除此之外，在碰到有依賴關(guān)系的模塊時，從內(nèi)核中卸載模塊的過程與載入的過程恰好相反，它遵循“first in last out“的準則，即在一系列有依賴關(guān)系的模塊中，必須先卸載最后加載進來的模塊，最后卸載最先加載進來的模塊。比如：如果要用 rmmod 移除正在使用中的模塊(如上例，要卸載slhc, 但仍有PPP模塊在使用它)會出現(xiàn)錯誤提示：Device or resource busy 。所以，在將PPP模塊從內(nèi)存中卸載后，才可能將slhc模塊從內(nèi)存中卸載。

總之，在卸載模塊時，對于可能出現(xiàn)的模塊間依賴性問題，linux會給你提示足夠的信息，仔細查看這些信息，是能夠為你采取相應(yīng)的操作并最終解決問題提供幫助的。

? ? ?21) 模塊和應(yīng)用程序分別運行在什么空間？

? ? ?22) Linux中的浮點運算由應(yīng)用程序?qū)崿F(xiàn)還是內(nèi)核實現(xiàn)？《內(nèi)核實現(xiàn)》

? ? ?23) 模塊程序能否使用可鏈接的庫函數(shù)？

? ? ?24) TLB中緩存的是什么內(nèi)容？

? ? ?25) Linux中有哪幾種設(shè)備？

? ? 必須先了解Linux所支持的CPU、RAM、顯卡等的硬件配備，以免造成無法安裝。此外，同時想、需要考慮即將架設(shè)的Linux主機的主要用途。

硬件設(shè)備 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Linux中的代號

IDE 硬盤 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/dev/hd[a-d]

SCSI硬盤 ? ? ? /dev/sd[a-p]

光驅(qū) ? ? ? ?/dev/cdrom

軟驅(qū) ? ? ? ?/dev/fd[0-1]

打印機 ? ? ? ?/dev/lp[0-2]

鼠標 ? ? ? ?/dev/mouse

磁盤 ? ? ? ?/dev/ht0(IDE)或/dev/st0 (SCSI界面)

網(wǎng) 卡 ? ? ? ?/dev/ethn (n由0開始)

? ? ?26) 字符設(shè)備驅(qū)動程序的關(guān)鍵數(shù)據(jù)結(jié)構(gòu)是哪個？

? ? ?27) 設(shè)備驅(qū)動程序包括哪些功能函數(shù)？

一、設(shè)備驅(qū)動程序的作用

? ?驅(qū)動程序是應(yīng)用程序和實際設(shè)備之間的一個軟件層。為用戶提供訪問設(shè)備的機制，而不是提供策略。不帶策略的驅(qū)動程序典型特征包括：同時支持同步和異步操作，驅(qū)動程序能被多次打開（并發(fā)使用）。

二、內(nèi)核功能劃分

? ? 進程管理：負責進程的創(chuàng)建和銷毀，進程間的通信，CPU調(diào)度

? ? 內(nèi)存管理：用來管理內(nèi)存，內(nèi)核為每個進程創(chuàng)建一個虛擬地址空間

? ? 文件系統(tǒng)：內(nèi)核在沒有結(jié)構(gòu)的硬件上構(gòu)造結(jié)構(gòu)化的文件系統(tǒng)，支持多文件系統(tǒng)

? ? 設(shè)備控制：也就是驅(qū)動程序

? ? 網(wǎng)絡(luò)功能：負責在應(yīng)用程序和網(wǎng)絡(luò)接口之間傳遞數(shù)據(jù)包，根據(jù)網(wǎng)絡(luò)活動控制程序的執(zhí)行。

三、可裝載模塊

? ? 在運行時添加模塊，linux內(nèi)核支持好幾種模塊類型，不只是設(shè)備驅(qū)動程序

四、設(shè)備和模塊的分類

? ? 字符設(shè)備：字符設(shè)備是個能夠像字符流一樣被訪問的設(shè)備，通常需要實現(xiàn)open close, read,write系統(tǒng)調(diào)用，大多數(shù)設(shè)備只能順序訪問。

? ? 塊設(shè)備：塊設(shè)備可以容納文件系統(tǒng)。進行i/o操作時塊設(shè)備只能傳輸一個或多個完成的塊，每塊包含512字節(jié)或2的更高次冪的數(shù)據(jù)。與字符設(shè)備相比，塊設(shè)備驅(qū)動程序有完全不同的接口。

? ? 網(wǎng)絡(luò)接口：網(wǎng)絡(luò)接口通常是個硬件，也可以是個軟件，由于不是面向流的設(shè)備，因此將網(wǎng)絡(luò)接口映射到文件系統(tǒng)中的節(jié)點比較困難，而是分配一個唯一的名字（eth0），但這個名字在文件系統(tǒng)中不存在對應(yīng)的節(jié)點。

? ? 某些模塊時通過某種設(shè)備的附加層一起空座(usb, scsi)

? ?文件系統(tǒng)是軟件驅(qū)動程序，將底層數(shù)據(jù)接口映射成高層數(shù)據(jù)結(jié)構(gòu)也可以在一個模塊中實現(xiàn)不同類型的設(shè)備驅(qū)動程序

五、安全問題

? ? 內(nèi)核有安全漏洞，則整個系統(tǒng)有安全漏洞，在正式發(fā)行版本中只有授權(quán)用戶才能裝在模塊

盡量避免在驅(qū)動中實現(xiàn)安全策略，最好在系統(tǒng)管理員的控制之下，而通常只有特權(quán)的用戶執(zhí)行，而相關(guān)的安全檢查必須由驅(qū)動程序本身完成。

六、版本編號

? ? 偶數(shù)為正式發(fā)行的穩(wěn)定版本

? ? 技術(shù)為開發(fā)過程中的一個快照

一、設(shè)置測試系統(tǒng)

? ? 在2.6內(nèi)核中構(gòu)造模塊，需要系統(tǒng)中中配置并構(gòu)造好內(nèi)核樹，先前的版本只需要有一套內(nèi)核頭文件。

? ? 2.6內(nèi)核的模塊要和內(nèi)核源碼樹中的目標文件連接，可得到一個更加健壯的模塊加載器。

二、HelloWord模塊

用到的宏

module_init

module_exit

分別制定了模塊和被加載或卸載時內(nèi)核調(diào)用的函數(shù)

MODULE_LICENSE(" " ) 高速內(nèi)核采用的自由許可證，如果沒有，模塊裝載時會產(chǎn)生抱怨

printk 類似c庫的printf 在內(nèi)核中模塊不能依賴于c庫，模塊裝載后可訪問內(nèi)核的公用符號(包括函數(shù)和變量)

KERN_ALERT 定義消息的優(yōu)先級只是個字符串如<1> 消息的顯示位置依賴內(nèi)核版本，klogd的版本和配置。

三核心模塊與應(yīng)用程序的對比

? ? 模塊退出時必須撤銷初始化函數(shù)所作的一切

? ? 內(nèi)核中只能調(diào)用作為內(nèi)核一部分的函數(shù)，大多數(shù)相關(guān)頭文件保存在include/linux和include/asm目錄中，其他子目錄中保存有和特定內(nèi)核子系統(tǒng)相關(guān)的頭文件。

調(diào)試方式不同和應(yīng)用程序不同。

四、用戶控件和內(nèi)核空間

? ? 內(nèi)核模塊運行在內(nèi)核空間，應(yīng)用程序運行在用戶空間

? ? 操作系統(tǒng)的作用是為應(yīng)用程序提供一個對計算機硬件的一致視圖。

? ? 操作系統(tǒng)負責程序的獨立操作并保護資源不受非法訪問。只有cpu能夠保護系統(tǒng)軟件不受應(yīng)用程序破壞時不受應(yīng)用程序破壞時才能完成！

? ? 在cpu中實現(xiàn)不同的操作模式，不同的級別具有不同的功能，在較低的級別中禁止某些操作。程序代碼只能通過有限數(shù)目的門來從一個級別切換到另一個級別。unix系統(tǒng)使用兩個級別，在x86中使用最高和最低兩個級別。

? ? unix中在最高級別（也稱超級用戶態(tài)）可運行所有操作，而應(yīng)用程序運行在最低級別（用戶態(tài)），處理器控制著對硬件的直接訪問以及對內(nèi)存的非授權(quán)訪問，兩個級別有自己的內(nèi)存映射，也即自己的地址空間

當應(yīng)用程序執(zhí)行系統(tǒng)調(diào)用或被硬件中斷刮起，將切換到內(nèi)核空間，執(zhí)行系統(tǒng)調(diào)用的內(nèi)核代碼運行在進程上下文中，因此能夠訪問進程地址空間的所有數(shù)據(jù)。處理中斷的內(nèi)核代碼和進程是異步的，與任何一個特定進程無關(guān)。

? ?模塊的兩類任務(wù)：

? ?1、模塊中某些函數(shù)作為系統(tǒng)調(diào)用的一部分

? ?2、其它函數(shù)負責中斷處理

五、內(nèi)核中的并發(fā)

? ? 內(nèi)核代碼必須是可重入的。

? ? 要時刻考慮并發(fā)問題

? ? ?28) 如何唯一標識一個設(shè)備？

在linux系統(tǒng)中，一切都是文件。所有的硬件設(shè)備也都被系統(tǒng)看作是文件，而這些硬件設(shè)備文件都存放在/dev目錄之下，但是這種設(shè)備文件有時候并不能唯一標識某一個硬件，最典型的例子就是那些可移動設(shè)備，比如U盤之類，當系統(tǒng)中接入U盤后，可能會將/dev/sda1這個設(shè)備名分配給它，但是假如這個U盤又插入到別的系統(tǒng)中了，那么可能它所分配到的設(shè)備名就不是/dev/sda1，可能變成了/dev/sdb1。如何讓它保持在任何系統(tǒng)中的標識都不變呢？當然是有辦法的，那就是UUID唯一性標識。還是以U盤為例，假如有一個U盤分了三個區(qū)，每個區(qū)都會分配有一個UUID，這個UUID是記錄在U盤上的，而不是在某一個系統(tǒng)中，這樣就不會出現(xiàn)U盤在不同的系統(tǒng)中設(shè)備名不同的問題。?

下面三個命令可以查看UUID號：?

1、ls -l /dev/disk/by-uuid/?

這個命令可以查看系統(tǒng)中所有具有UUID的設(shè)備文件信息?

2. vol_id /dev/sdb1?

查看/dev/sdb1的卷ID，也就是UUID?

3. blkid /dev/sdb1?

查看塊設(shè)備/dev/sdb1的UUID，像硬盤、U盤、光盤等之類的存儲設(shè)備都是塊設(shè)備，都可以用這個命令來查看UUID?

? ? ?29) Linux通過什么方式實現(xiàn)系統(tǒng)調(diào)用？

1.linux系統(tǒng)調(diào)用的基本原理

linux的系統(tǒng)調(diào)用形式與POSIX兼容，也是一套C語言函數(shù)名的集合。然而，linux系統(tǒng)調(diào)用的內(nèi)部實現(xiàn)方式卻與DOC的INT 21H相似，它是經(jīng)過INT 0X80H軟中斷進入后，再根據(jù)系統(tǒng)調(diào)用號分門別類地服務(wù)。

從系統(tǒng)分析的角度，linux的系統(tǒng)調(diào)用涉及4個方面的問題。

(1)與系統(tǒng)調(diào)用有關(guān)的數(shù)據(jù)結(jié)構(gòu)和函數(shù)

函數(shù)名以“sys_”開頭，后跟該系統(tǒng)調(diào)用的名字。例如，系統(tǒng)調(diào)用fork()的響應(yīng)函數(shù)是sys_fork()(見Kernel/fork.c),exit()的響應(yīng)函數(shù)是sys_exit()(見kernel/fork.c)。

文件include/asm/unisted.h為每個系統(tǒng)調(diào)用規(guī)定了唯一的編號。假設(shè)用name表示系統(tǒng)調(diào)用的名稱，那么系統(tǒng)調(diào)用號與系統(tǒng)調(diào)用響應(yīng)函數(shù)的關(guān)系是：以系統(tǒng)調(diào)用號_NR_name作為下標，可找出系統(tǒng)調(diào)用表sys_call_table(見

arch/i386/kernel/entry.S)中對應(yīng)表項的內(nèi)容，它正好是該系統(tǒng)調(diào)用的響應(yīng)函數(shù)sys_name的入口地址。系統(tǒng)調(diào)用表sys_call_table記錄了各sys_name函數(shù)在表中的位置，共190項。有了這張表，就很容易根據(jù)特定系統(tǒng)調(diào)用在表中的偏移量，找到對應(yīng)的系統(tǒng)調(diào)用響應(yīng)函數(shù)的入口地址。系統(tǒng)調(diào)用表共256項，余下的項是可供用戶自己添加的系統(tǒng)調(diào)用空間。

(2)進程的系統(tǒng)調(diào)用命令轉(zhuǎn)換為INT 0x80中斷的過程

宏定義_syscallN()見include/asm/unisted.h)用于系統(tǒng)調(diào)用的格式轉(zhuǎn)換和參數(shù)的傳遞。N取0~5之間的整數(shù)。參數(shù)個數(shù)為N的系統(tǒng)調(diào)用由_syscallN()負責格式轉(zhuǎn)換和參數(shù)傳遞。系統(tǒng)調(diào)用號放入EAX寄存器，啟動INT 0x80 后，規(guī)定返回值送EAX寄存器。

(3)系統(tǒng)調(diào)用功能模塊的初始化

對系統(tǒng)調(diào)用的初始化也就是對INT 0x80的初始化。系統(tǒng)啟動時，匯編子程序setup_idt(見arch/i386/kernel/head.S)準備了1張256項的idt表，由 start_kernel()(見 init/main.c),trap_init()(見

arch/i386/kernel/traps.c)調(diào)用的C語言宏定義

set_system_gate(0x80,&system_call)(見include/asm/system.h)設(shè)置0x80號軟中斷的服務(wù)程序為 system_call(見

arch/i386/kernel/entry.S),system.call就是所有系統(tǒng)調(diào)用的總?cè)肟凇?/p>

(4)內(nèi)核如何為各種系統(tǒng)調(diào)用服務(wù)

當進程需要進行系統(tǒng)調(diào)用時，必須以C語言函數(shù)的形式寫一句系統(tǒng)調(diào)用命令。該命令如果已在某個頭文件中由相應(yīng)的_syscallN()展開，則用戶程序必須包含該文件。當進程執(zhí)行到用戶程序的系統(tǒng)調(diào)用命令時，實際上執(zhí)行了由宏命令_syscallN()展開的函數(shù)。系統(tǒng)調(diào)用的參數(shù) 由各通用寄存器傳遞，然后執(zhí)行INT 0x80，以內(nèi)核態(tài)進入入口地址system_call。

(5)ret_from_sys_call

以ret_from_sys_call入口的匯編程序段在linux進程管理中起到了十分重要的作用。所有系統(tǒng)調(diào)用結(jié)束前以及大部分中斷服務(wù)返回前，都會跳轉(zhuǎn)至此處入口地址。該段程序不僅僅為系統(tǒng)調(diào)用服務(wù)，它還處理中斷嵌套、CPU調(diào)度、信號等事務(wù)。

2.通過修改內(nèi)核源代碼添加系統(tǒng)調(diào)用

通過以上分析linux系統(tǒng)調(diào)用的過程，將自己的系統(tǒng)調(diào)用加到內(nèi)核中就是一件容易的事情。下面介紹一個實際的系統(tǒng)調(diào)用，并把它加到內(nèi)核中去。要增加的系統(tǒng)調(diào)用是：inttestsyscall()，其功能是在控制終端屏幕上顯示hello world，執(zhí)行成功后返回0。

1編寫inttestsyscall()系統(tǒng)調(diào)用

編寫一個系統(tǒng)調(diào)用意味著要給內(nèi)核增加1個函數(shù)，將新函數(shù)放入文件kernel/sys.c中。新函數(shù)代碼如下：

asmlingkage sys_testsyscall()

{ console_print("hello world\n");

return 0;

}

2連接新的系統(tǒng)調(diào)用

編寫了新的系統(tǒng)調(diào)用過程后，下一項任務(wù)是使內(nèi)核的其余部分知道這一程序的存在，然后重建包含新的系統(tǒng)調(diào)用的內(nèi)核。為了把新的函數(shù)連接到已有的內(nèi)核中去，需要編輯2個文件：

1).inculde/asm/unistd.h在這個文件中加入

#define_NR_testsyscall 191

2).are/i386/kernel/entry.s這個文件用來對指針數(shù)組初始化，在這個文件中增加一行：

.long SYMBOL_NAME(_sys_tsetsycall)

將.rept NR_syscalls-190改為NR_SYSCALLS-191,然后重新獎勵和運行新內(nèi)核。

3).使用新的系統(tǒng)調(diào)用

在保證的C語言庫中沒有新的系統(tǒng)調(diào)用的程序段，必須自己建立其代碼如下

#inculde

_syscall0(int,testsyscall)

main()

{

tsetsyscall();

}

在這里使用了_syscall0()宏指令，宏指令本身在程序中將擴展成名為syscall()的函數(shù)，它在main()函數(shù)內(nèi)部加以調(diào)用。在testsyscall()函數(shù)中，預(yù)處理程序產(chǎn)生所有必要的機器指令代碼，包括用系統(tǒng)調(diào)用參數(shù)值加載相應(yīng)的cpu寄存器，然后執(zhí)行int 0x80中斷指令。

3.利用內(nèi)核模塊添加系統(tǒng)調(diào)用

模塊是內(nèi)核的一部分，但是并沒有被編譯到內(nèi)核里面去。它們被分別編譯并連接成一組目標文件，這些文件能被插入到正在運行的內(nèi)核，或者從正在運行的內(nèi)核中移走。內(nèi)核模塊至少必須有2個函數(shù)：

int_module和cleanup_module。第一個函數(shù)是在把模塊插入內(nèi)核時調(diào)用的;第二個函數(shù)則在刪除該模塊時調(diào)用。由于內(nèi)核模塊是內(nèi)核的一部分，所以能訪問所有內(nèi)核資源。根據(jù)對linux系統(tǒng)調(diào)用機制的分析，如果要增加系統(tǒng)調(diào)用，可以編寫自己的函數(shù)來實現(xiàn)，然后在sys_call_table表中增加一項，使該項中的指針指向自己編寫的函數(shù)，就可以實現(xiàn)系統(tǒng)調(diào)用。下面用該方法實現(xiàn)在控制終端上打印“hello world” 的系統(tǒng)調(diào)用testsyscall()。

1)編寫系統(tǒng)調(diào)用內(nèi)核模塊

#inculde(linux/kernel.h)

#inculde(linux/module.h)

#inculde(linux/modversions.h)

#inculde(linux/sched.h)

#inculde(asm/uaccess.h)

#define_NR_testsyscall 191

extern viod *sys_call+table[];

asmlinkage int testsyscall()

{ printf("hello world\n");

return 0;

}

int init_module()

{ sys_call_table[_NR_tsetsyscall]=testsyscall;

printf("system call testsyscall() loaded success\n");

return 0;

}

void cleanup_module()

{

}

2)使用新的系統(tǒng)調(diào)用#define

#define_NR_testsyscall 191

_syscall0(int,testsyscall)

main()

{

testsyscall();

}

3)編譯內(nèi)核模塊并插入內(nèi)核

編譯內(nèi)核的命令為：gcc -Wall -02 -DMODULE -D_KERNEL_-C syscall.c

-Wall通知編譯程序顯示警告信息;參數(shù)-02 是關(guān)于代碼優(yōu)化的設(shè)置，內(nèi)核模塊必須優(yōu)化;參數(shù)-D_LERNEL通知頭文件向內(nèi)核模塊提供正確的定義; 參數(shù)-D_KERNEL_通知頭文件，這個程序代碼將在內(nèi)核模式下運行。編譯成功后將生成 syscall.0文件。最后使用insmod syscall.o命令將模塊插入內(nèi)核后即可使用增加的系統(tǒng)調(diào)用。

比較以上二種方法，筆者認為采用內(nèi)核模塊的方法較好。因為這種方法可省去編譯新內(nèi)核并用新內(nèi)核重新啟動的麻煩，這一優(yōu)點對于代碼的調(diào)試是非常有價值的，可以節(jié)省大量時間。

原文出自【比特網(wǎng)】，轉(zhuǎn)載請保留原文鏈接：http://soft.chinabyte.com/os/368/11655868.shtml

? ? ?30) Linux軟中斷和工作隊列的作用是什么？

總結(jié)

以上是生活随笔為你收集整理的嵌入式系统Linux内核开发工程师必须掌握的三十道题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

上一篇：基于SSH的宠物管理系统（宠物商店）
下一篇：桩训日记