linux調度原理

Ⅰ 嵌入式linux要學哪些

您好，關於該問題，解答如下：
嵌入式linux要學什麼：
1.Linux 基礎

安裝Linux操作系統 Linux文件系統 Linux常用命令 Linux啟動過程詳解 熟悉Linux服務能夠獨立安裝Linux操作系統 能夠熟練使用Linux系統的基本命令 認識Linux系統的常用服務安裝Linux操作系統 Linux基本命令實踐 設置Linux環境變數 定製Linux的服務 Shell 編程基礎使用vi編輯文件 使用Emacs編輯文件 使用其他編輯器

2.Linux 下的 C 編程基礎

linux C語言環境概述 Gcc使用方法 Gdb調試技術 Autoconf Automake Makefile 代碼優化 熟悉Linux系統下的開發環境 熟悉Gcc編譯器 熟悉Makefile規則編寫Hello,World程序 使用 make命令編譯程序 編寫帶有一個循環的程序 調試一個有問題的程序

3.Shell 編程基礎

Shell 簡介 認識後台程序Bash編程熟悉Linux系統下的編輯環境 熟悉Linux下的各種Shell 熟練進行shell編程熟悉vi基本操作 熟悉Emacs的基本操作 比較不同shell的區別 編寫一個測試伺服器是否連通的shell腳本程序 編寫一個查看進程是否存在的shell腳本程序 編寫一個帶有循環語句的shell腳本程序

4.嵌入式系統開發基礎

嵌入式系統概述 交叉編譯 配置TFTP服務 配置NFS服務 下載Bootloader和內核 嵌入式Linux應用軟體開發流程熟悉嵌入式系統概念以及開發流程 建立嵌入式系統開發環境製作cross_gcc工具鏈 編譯並下載U-boot 編譯並下載Linux內核 編譯並下載Linux應用程序

5.嵌入式系統移植

Linux內核代碼 平台相關代碼分析 ARM平台介紹 平台移植的關鍵技術 移植Linux內核到 ARM平台 了解移植的概念 能夠移植Linux內核移植Linux2.6內核到 ARM9開發板

6.嵌入式Linux下串口通信

串列I/O的基本概念 嵌入式Linux應用軟體開發流程 Linux系統的文件和設備 與文件相關的系統調用 配置超級終端和MiniCOM 能夠熟悉進行串口通信 熟悉文件I/O 編寫串口通信程序 編寫多串口通信程序

7.嵌入式系統中多進程程序設計

Linux系統進程概述 嵌入式系統的進程特點 進程操作 守護進程 相關的系統調用了解Linux系統中進程的概念 能夠編寫多進程程序編寫多進程程序 編寫一個守護進程程序 sleep系統調用任務管理、同步與通信 Linux任務概述任務調度 管道 信號 共享內存 任務管理 API 了解Linux系統任務管理機制 熟悉進程間通信的幾種方式 熟悉嵌入式Linux中的任務間同步與通信編寫一個簡單的管道程序實現文件傳輸 編寫一個使用共享內存的程序

8.嵌入式系統中多線程程序設計

線程的基礎知識 多線程編程方法 線程應用中的同步問題了解線程的概念 能夠編寫簡單的多線程程序編寫一個多線程程序

9.嵌入式 Linux 網路編程

網路基礎知識 嵌入式Linux中TCP/IP網路結構 socket 編程 常用 API函數 分析Ping命令的實現 基本UDP套介面編程 許可證管理 PPP協議 GPRS 了解嵌入式Linux網路體系結構 能夠進行嵌入式Linux環境下的socket 編程 熟悉UDP協議、PPP協議 熟悉GPRS 使用socket 編寫代理伺服器 使用socket 編寫路由器 編寫許可證伺服器 指出TCP和UDP的優缺點 編寫一個web伺服器 編寫一個運行在 ARM平台的網路播放器

10.Linux 字元設備驅動程序

設備驅動程序基礎知識 Linux系統的模塊 字元設備驅動分析 fs_operation結構 載入驅動程序了解設備驅動程序的概念 了解Linux字元設備驅動程序結構 能夠編寫字元設備驅動程序編寫Skull驅動 編寫鍵盤驅動 編寫I/O驅動 分析一個看門狗驅動程序 對比Linux2.6內核與2.4內核中字元設備驅動的不同Linux 塊設備驅動程序塊設備驅動程序工作原理 典型的塊設備驅動程序分析 塊設備的讀寫請求隊列了解Linux塊設備驅動程序結構 能夠編寫簡單的塊設備驅動程序比較字元設備與塊設備的異同 編寫MMC卡驅動程序 分析一個文件系統 對比Linux2.6內核與2.4內核中塊設備驅動的不同

11.GUI 程序開發

GUI基礎 嵌入式系統GUI類型 編譯QT 進行QT開發熟悉嵌入式系統常用的GUI 能夠進行QT編程使用QT編寫「Hello，World」程序 調試一個加入信號/槽的實例 通過重載QWidget 類方法處理事件

12.文件系統

虛擬文件系統文件系統的建立 ramfs內存文件系統 proc文件系統 devfs 文件系統 MTD技術簡介 MTD塊設備初始化 MTD塊設備的讀寫操作了解Linux系統的文件系統了解嵌入式Linux的文件系統了解MTD技術 能夠編寫簡單的文件系統為 ARM9開發板添加 MTD支持移植JFFS2文件系統 通過proc文件系統修改操作系統參數 分析romfs 文件系統源代碼 創建一個cramfs 文件系統
——如有幫助，請採納一下。

Ⅱ Linux課程主要講什麼內容

Linux學習，主要學以下內容：
第一階段：linux基礎入門
1. 開班課程介紹-規章制度介紹-破冰活動；
2. Linux硬體基礎/Linux發展歷史；
3. Linux系統安裝/xshell連接/xshell優化/SSH遠程連接故障問題排查
4. 第一關一大波命令及特殊字元知識考試題講解
5. Linux基礎優化
6. Linux目錄結構知識精講
7. 第二關一大波命令及特殊
知識考試題講解（上）
8. 第二關一大波命令及特殊知識考試題講解（下）
9. Linux文件屬性一大堆知識精講
10. Linux通配符/正則表達式
11. 第三關一大波命令及重要知識考試題講解（上）
12. 第三關一大波命令及重要知識考試題講解（下）
13. Linux系統許可權(上)
14. Linux系統許可權(下)
15. 第一階段結束需要導師或講師對整體課程進行回顧
第二階段：linux系統管理進階
1. Linux定時任務
2. Linux用戶管理
3. Linux磁碟與文件系統(上)
4. Linux磁碟與文件系統(中下)
5. Linux三劍客之sed命令
第三階段：Linux Shell基礎
1. Shell編程基礎1
2. Shell編程基礎234
3. Linux三劍客之awk命令
第四階段：Linux網路基礎
1. 計算機網路基礎上
2. 計算機網路基礎下
3. 第二階段結束需要導師或講師對整體課程進行回顧。
第五階段：Linux網路服務
1. 集群實戰架構開始及環境准備
2. rsync數據同步服務
3. Linux全網備份項目案例精講
4. nfs網路存儲服務精講
5. inotify/sersync實時數據同步/nfs存儲實時備份項目案例精講
第六階段：Linux重要網路服務
1. http協議/www服務基礎
2. nginx web介紹及基礎實踐
3. nginx web精講結束
4. lnmp環境部署/資料庫異機遷移/共享數據異機遷移到NFS系統
5. nginx負載均衡深入透徹
6. keepalived高可用深入透徹
第七階段：Linux中小規模集群構建與優化（50台）
1. 期中架構開戰說明+期中架構部署回顧
2. 全體晝夜兼程部署期中架構並完成上台述職演講（加上兩個周末共9天）
3. kickstart cobbler 批量自動安裝系統
4. pptp vpn與ntp服務
5. memcached原理及部署/作為緩存及session會話共享
第八階段：Ansible自動化運維與Zabbix監控
1. SSH服務秘鑰認證
2. ansible批量自動化管理集群（入門及深入）
3. zabbix監控
第九階段：大規模集群高可用服務(Lvs、Keepalived)
1. Centos7系統自行安裝/centos6與7區別
2. lvs負載均衡集群/keepalived管理LVS集群
第十階段：java Tomcat服務及防火牆Iptables
1. iptables防火牆精講上
2. iptables防火牆精講下
3. tomcat java應用服務/nginx配合tomcat服務部署及優化
第十一階段：MySQL DBA高級應用實踐
1. MySQL資料庫入門基礎命令
2. MySQL資料庫進階備份恢復
3. MySQL資料庫深入事務引擎
4. MySQL資料庫優化SQL語句優化
5. MySQL資料庫集群主從復制/讀寫分離
6. MySQL資料庫高可用/mha/keepalved
第十二階段：高性能資料庫Redis和Memcached課程
第十三階段：Linux大規模集群架構構建（200台）
第十四階段：Linux Shell編程企業案例實戰
第十五階段：企業級代碼發布上線方案（SVN和Git）
1. GIT管理
2. 代碼上線項目案例
第十六階段企業級Kvm虛擬化與OpenStack雲計算
1. KVM虛擬化企業級實戰
2. OpenStack雲計算企業級實戰
第十七階段公有雲阿里雲8大組件構建集群實戰
第十八階段：Docker技術企業應用實踐
1. Docker容器與微服務深入實踐
2. 大數據Hadoop生態體系及實踐
第十九階段：Python自動化入門及進階
第二十階段：職業規劃與高薪就業指導

Ⅲ 進程調度的Linux 原理

1，SCHED_OTHER 分時調度策略，
2，SCHED_FIFO實時調度策略，先到先服務
3，SCHED_RR實時調度策略，時間片輪轉
實時進程將得到優先調用，實時進程根據實時優先順序決定調度權值，分時進程則通過nice和counter值決定權值，nice越小，counter越大，被調度的概率越大，也就是曾經使用了cpu最少的進程將會得到優先調度。
SHCED_RR和SCHED_FIFO的不同：
當採用SHCED_RR策略的進程的時間片用完，系統將重新分配時間片，並置於就緒隊列尾。放在隊列尾保證了所有具有相同優先順序的RR任務的調度公平。
SCHED_FIFO一旦佔用cpu則一直運行。一直運行直到有更高優先順序任務到達或自己放棄。
如果有相同優先順序的實時進程（根據優先順序計算的調度權值是一樣的）已經准備好，FIFO時必須等待該進程主動放棄後才可以運行這個優先順序相同的任務。而RR可以讓每個任務都執行一段時間。
相同點：
RR和FIFO都只用於實時任務。
創建時優先順序大於0(1-99)。
按照可搶占優先順序調度演算法進行。
就緒態的實時任務立即搶占非實時任務。
所有任務都採用linux分時調度策略時。
1，創建任務指定採用分時調度策略，並指定優先順序nice值(-20~19)。
2，將根據每個任務的nice值確定在cpu上的執行時間(counter)。
3，如果沒有等待資源，則將該任務加入到就緒隊列中。
4，調度程序遍歷就緒隊列中的任務，通過對每個任務動態優先順序的計算(counter+20-nice)結果，選擇計算結果最大的一個去運行，當這個時間片用完後(counter減至0)或者主動放棄cpu時，該任務將被放在就緒隊列末尾(時間片用完)或等待隊列(因等待資源而放棄cpu)中。
5，此時調度程序重復上面計算過程，轉到第4步。
6，當調度程序發現所有就緒任務計算所得的權值都為不大於0時，重復第2步。
所有任務都採用FIFO時，
1，創建進程時指定採用FIFO，並設置實時優先順序rt_priority(1-99)。
2，如果沒有等待資源，則將該任務加入到就緒隊列中。
3，調度程序遍歷就緒隊列，根據實時優先順序計算調度權值(1000+rt_priority)，選擇權值最高的任務使用cpu，該FIFO任務將一直佔有cpu直到有優先順序更高的任務就緒(即使優先順序相同也不行)或者主動放棄(等待資源)。
4，調度程序發現有優先順序更高的任務到達(高優先順序任務可能被中斷或定時器任務喚醒，再或被當前運行的任務喚醒，等等)，則調度程序立即在當前任務堆棧中保存當前cpu寄存器的所有數據，重新從高優先順序任務的堆棧中載入寄存器數據到cpu，此時高優先順序的任務開始運行。重復第3步。
5，如果當前任務因等待資源而主動放棄cpu使用權，則該任務將從就緒隊列中刪除，加入等待隊列，此時重復第3步。
所有任務都採用RR調度策略時
1，創建任務時指定調度參數為RR，並設置任務的實時優先順序和nice值(nice值將會轉換為該任務的時間片的長度)。
2，如果沒有等待資源，則將該任務加入到就緒隊列中。
3，調度程序遍歷就緒隊列，根據實時優先順序計算調度權值(1000+rt_priority)，選擇權值最高的任務使用cpu。
4，如果就緒隊列中的RR任務時間片為0，則會根據nice值設置該任務的時間片，同時將該任務放入就緒隊列的末尾。重復步驟3。
5，當前任務由於等待資源而主動退出cpu，則其加入等待隊列中。重復步驟3。
系統中既有分時調度，又有時間片輪轉調度和先進先出調度
1，RR調度和FIFO調度的進程屬於實時進程，以分時調度的進程是非實時進程。
2，當實時進程准備就緒後，如果當前cpu正在運行非實時進程，則實時進程立即搶占非實時進程。
3，RR進程和FIFO進程都採用實時優先順序做為調度的權值標准，RR是FIFO的一個延伸。FIFO時，如果兩個進程的優先順序一樣，則這兩個優先順序一樣的進程具體執行哪一個是由其在隊列中的未知決定的，這樣導致一些不公正性(優先順序是一樣的，為什麼要讓你一直運行？)，如果將兩個優先順序一樣的任務的調度策略都設為RR，則保證了這兩個任務可以循環執行，保證了公平。 調度程序運行時，要在所有處於可運行狀態的進程之中選擇最值得運行的進程投入運行。選擇進程的依據是什麼呢？在每個進程的task_struct 結構中有這么四項：
policy， priority ， counter， rt_priority
這四項就是調度程序選擇進程的依據.其中，policy是進程的調度策略，用來區分兩種進程-實時和普通；priority是進程(實時和普通)的優先順序；counter 是進程剩餘的時間片，它的大小完全由priority決定；rt_priority是實時優先順序，這是實時進程所特有的，用於實時進程間的選擇。
首先，Linux 根據policy從整體上區分實時進程和普通進程，因為實時進程和普通進程度調度是不同的，它們兩者之間，實時進程應該先於普通進程而運行，然後，對於同一類型的不同進程，採用不同的標准來選擇進程：
對於普通進程，Linux採用動態優先調度，選擇進程的依據就是進程counter的大小。進程創建時，優先順序priority被賦一個初值，一般為0～70之間的數字，這個數字同時也是計數器counter的初值，就是說進程創建時兩者是相等的。字面上看，priority是「優先順序」、counter是「計數器」的意思，然而實際上，它們表達的是同一個意思-進程的「時間片」。Priority代表分配給該進程的時間片，counter表示該進程剩餘的時間片。在進程運行過程中，counter不斷減少，而priority保持不變，以便在counter變為0的時候（該進程用完了所分配的時間片）對counter重新賦值。當一個普通進程的時間片用完以後，並不馬上用priority對counter進行賦值，只有所有處於可運行狀態的普通進程的時間片(p->；；counter==0)都用完了以後，才用priority對counter重新賦值，這個普通進程才有了再次被調度的機會。這說明，普通進程運行過程中，counter的減小給了其它進程得以運行的機會，直至counter減為0時才完全放棄對CPU的使用，這就相對於優先順序在動態變化，所以稱之為動態優先調度。至於時間片這個概念，和其他不同操作系統一樣的，Linux的時間單位也是「時鍾滴答」，只是不同操作系統對一個時鍾滴答的定義不同而已（Linux為10ms）。進程的時間片就是指多少個時鍾滴答，比如，若priority為20，則分配給該進程的時間片就為20個時鍾滴答，也就是20*10ms=200ms。Linux中某個進程的調度策略(policy)、優先順序(priority)等可以作為參數由用戶自己決定，具有相當的靈活性。內核創建新進程時分配給進程的時間片預設為200ms(更准確的，應為210ms)，用戶可以通過系統調用改變它。
對於實時進程，Linux採用了兩種調度策略，即FIFO(先來先服務調度)和RR（時間片輪轉調度）。因為實時進程具有一定程度的緊迫性，所以衡量一個實時進程是否應該運行，Linux採用了一個比較固定的標准。實時進程的counter只是用來表示該進程的剩餘時間片，並不作為衡量它是否值得運行的標准，這和普通進程是有區別的。上面已經看到，每個進程有兩個優先順序，實時優先順序就是用來衡量實時進程是否值得運行的。
這一切看來比較麻煩，但實際上Linux中的實現相當簡單。Linux用函數goodness()來衡量一個處於可運行狀態的進程值得運行的程度。該函數綜合了上面提到的各個方面，給每個處於可運行狀態的進程賦予一個權值(weight)，調度程序以這個權值作為選擇進程的唯一依據。
Linux根據policy的值將進程總體上分為實時進程和普通進程，提供了三種調度演算法：一種傳統的Unix調度程序和兩個由POSIX.1b(原名為POSIX.4)操作系統標准所規定的「實時」調度程序。但這種實時只是軟實時，不滿足諸如中斷等待時間等硬實時要求，只是保證了當實時進程需要時一定只把CPU分配給實時進程。
非實時進程有兩種優先順序，一種是靜態優先順序，另一種是動態優先順序。實時進程又增加了第三種優先順序，實時優先順序。優先順序是一些簡單的整數，為了決定應該允許哪一個進程使用CPU的資源，用優先順序代表相對權值-優先順序越高，它得到CPU時間的機會也就越大。
？ 靜態優先順序(priority)-不隨時間而改變，只能由用戶進行修改。它指明了在被迫和其他進程競爭CPU之前，該進程所應該被允許的時間片的最大值（但很可能的，在該時間片耗盡之前，進程就被迫交出了CPU）。
？ 動態優先順序(counter)-只要進程擁有CPU，它就隨著時間不斷減小；當它小於0時，標記進程重新調度。它指明了在這個時間片中所剩餘的時間量。
？ 實時優先順序(rt_priority)-指明這個進程自動把CPU交給哪一個其他進程；較高權值的進程總是優先於較低權值的進程。如果一個進程不是實時進程，其優先順序就是0，所以實時進程總是優先於非實時進程的（但實際上，實時進程也會主動放棄CPU）。
當policy分別為以下值時：
1) SCHED_OTHER：這是普通的用戶進程，進程的預設類型，採用動態優先調度策略，選擇進程的依據主要是根據進程goodness值的大小。這種進程在運行時，可以被高goodness值的進程搶先。
2) SCHED_FIFO：這是一種實時進程，遵守POSIX1.b標準的FIFO(先入先出)調度規則。它會一直運行，直到有一個進程因I/O阻塞，或者主動釋放CPU，或者是CPU被另一個具有更高rt_priority的實時進程搶先。在Linux實現中，SCHED_FIFO進程仍然擁有時間片-只有當時間片用完時它們才被迫釋放CPU。因此，如同POSIX1.b一樣，這樣的進程就象沒有時間片(不是採用分時)一樣運行。Linux中進程仍然保持對其時間片的記錄（不修改counter）主要是為了實現的方便，同時避免在調度代碼的關鍵路徑上出現條件判斷語句 if (！(current->；；policy&；；SCHED_FIFO)){...}-要知道，其他大量非FIFO進程都需要記錄時間片，這種多餘的檢測只會浪費CPU資源。（一種優化措施，不該將執行時間佔10%的代碼的運行時間減少到50%；而是將執行時間佔90%的代碼的運行時間減少到95%。0.9+0.1*0.5=0.95>；；0.1+0.9*0.9=0.91）
3) SCHED_RR：這也是一種實時進程，遵守POSIX1.b標準的RR(循環round-robin)調度規則。除了時間片有些不同外，這種策略與SCHED_FIFO類似。當SCHED_RR進程的時間片用完後，就被放到SCHED_FIFO和SCHED_RR隊列的末尾。
只要系統中有一個實時進程在運行，則任何SCHED_OTHER進程都不能在任何CPU運行。每個實時進程有一個rt_priority，因此，可以按照rt_priority在所有SCHED_RR進程之間分配CPU。其作用與SCHED_OTHER進程的priority作用一樣。只有root用戶能夠用系統調用sched_setscheler，來改變當前進程的類型(sys_nice，sys_setpriority)。
此外，內核還定義了SCHED_YIELD，這並不是一種調度策略，而是截取調度策略的一個附加位。如同前面說明的一樣，如果有其他進程需要CPU，它就提示調度程序釋放CPU。特別要注意的就是這甚至會引起實時進程把CPU釋放給非實時進程。 真正執行調度的函數是schele(void)，它選擇一個最合適的進程執行，並且真正進行上下文切換，使得選中的進程得以執行。而reschele_idle(struct task_struct *p)的作用是為進程選擇一個合適的CPU來執行，如果它選中了某個CPU，則將該CPU上當前運行進程的need_resched標志置為1，然後向它發出一個重新調度的處理機間中斷，使得選中的CPU能夠在中斷處理返回時執行schele函數，真正調度進程p在CPU上執行。在schele()和reschele_idle()中調用了goodness()函數。goodness()函數用來衡量一個處於可運行狀態的進程值得運行的程度。此外，在schele()函數中還調用了schele_tail()函數；在reschele_idle()函數中還調用了reschele_idle_slow()。這些函數的實現對理解SMP的調度非常重要，下面一一分析這些函數。先給出每個函數的主要流程圖，然後給出源代碼，並加註釋。
goodness()函數分析
goodness()函數計算一個處於可運行狀態的進程值得運行的程度。一個任務的goodness是以下因素的函數：正在運行的任務、想要運行的任務、當前的CPU。goodness返回下面兩類值中的一個：1000以下或者1000以上。1000或者1000以上的值只能賦給「實時」進程，從0到999的值只能賦給普通進程。實際上，在單處理器情況下，普通進程的goodness值只使用這個范圍底部的一部分，從0到41。在SMP情況下，SMP模式會優先照顧等待同一個處理器的進程。不過，不管是UP還是SMP，實時進程的goodness值的范圍是從1001到1099。
goodness()函數其實是不會返回-1000的，也不會返回其他負值。由於idle進程的counter值為負，所以如果使用idle進程作為參數調用goodness，就會返回負值，但這是不會發生的。
goodness()是個簡單的函數，但是它是linux調度程序不可缺少的部分。運行隊列中的每個進程每次執行schele時都要調度它，因此它的執行速度必須很快。
//在/kernel/sched.c中
static inline int goodness(struct task_struct * p， int this_cpu， struct mm_struct *this_mm)
{ int weight；
if (p->；；policy ！= SCHED_OTHER) {/*如果是實時進程，則*/
weight = 1000 + p->；；rt_priority；
goto out；
}
/* 將counter的值賦給weight，這就給了進程一個大概的權值，counter中的值表示進程在一個時間片內，剩下要運行的時間.*/
weight = p->；；counter；
if (！weight) /* weight==0，表示該進程的時間片已經用完，則直接轉到標號out*/
goto out；
#ifdef __SMP__
/*在SMP情況下，如果進程將要運行的CPU與進程上次運行的CPU是一樣的，則最有利，因此，假如進程上次運行的CPU與當前CPU一致的話，權值加上PROC_CHANGE_PENALTY，這個宏定義為20。*/
if (p->；；processor == this_cpu)
weight += PROC_CHANGE_PENALTY；
#endif
if (p->；；mm == this_mm) /*進程p與當前運行進程，是同一個進程的不同線程，或者是共享地址空間的不同進程，優先選擇，權值加1*/
weight += 1；
weight += p->；；priority； /* 權值加上進程的優先順序*/
out：
return weight； /* 返回值作為進程調度的唯一依據，誰的權值大，就調度誰運行*/
}
schele()函數分析
schele()函數的作用是，選擇一個合適的進程在CPU上執行，它僅僅根據'goodness'來工作。對於SMP情況，除了計算每個進程的加權平均運行時間外，其他與SMP相關的部分主要由goodness()函數來體現。
流程：
①將prev和next設置為schele最感興趣的兩個進程：其中一個是在調用schele時正在運行的進程(prev)，另外一個應該是接著就給予CPU的進程（next）。注意：prev和next可能是相同的-schele可以重新調度已經獲得cpu的進程.
②中斷處理程序運行「下半部分」.
③內核實時系統部分的實現，循環調度程序（SCHED_RR）通過移動「耗盡的」RR進程-已經用完其時間片的進程-到隊列末尾，這樣具有相同優先順序的其他RR進程就可以獲得CPU了。同時，這補充了耗盡進程的時間片。
④由於代碼的其他部分已經決定了進程必須被移進或移出TASK_RUNNING狀態，所以會經常使用schele，例如，如果進程正在等待的硬體條件已經發生，所以如果必要，這個switch會改變進程的狀態。如果進程已經處於TASK_RUNNING狀態，它就無需處理了。如果它是可以中斷的（等待信號），並且信號已經到達了進程，就返回TASK_RUNNING狀態。在所以其他情況下（例如，進程已經處於TASK_UNINTERRUPTIBLE狀態了），應該從運行隊列中將進程移走。
⑤將p初始化為運行隊列的第一個任務；p會遍歷隊列中的所有任務。
⑥c記錄了運行隊列中所有進程最好的「goodness」-具有最好「goodness」的進程是最易獲得CPU的進程。goodness的值越高越好。
⑦遍歷執行任務鏈表，跟蹤具有最好goodness的進程。
⑧這個循環中只考慮了唯一一個可以調度的進程。在SMP模式下，只有任務不在cpu上運行時，即can_schele宏返回為真時，才會考慮該任務。在UP情況下，can_schele宏返回恆為真.
⑨如果循環結束後，得到c的值為0。說明運行隊列中的所有進程的goodness值都為0。goodness的值為0，意味著進程已經用完它的時間片，或者它已經明確說明要釋放CPU。在這種情況下，schele要重新計算進程的counter；新counter的值是原來值的一半加上進程的靜態優先順序（priortiy），除非進程已經釋放CPU，否則原來counter的值為0。因此，schele通常只是把counter初始化為靜態優先順序。（中斷處理程序和由另一個處理器引起的分支在schele搜尋goodness最大值時都將增加此循環中的計數器，因此由於這個原因計數器可能不會為0。顯然，這很罕見。）在counter的值計算完成後，重新開始執行這個循環，找具有最大goodness的任務。
⑩如果schele已經選擇了一個不同於前面正在執行的進程來調度，那麼就必須掛起原來的進程並允許新的進程運行。這時調用switch_to來進行切換。

Ⅳ 為什麼Linux CFS調度器沒有帶來驚艷的碾壓效果| CSDN博文精選

任何領域，革命性的碾壓式推陳出新並不是沒有，但是概率極低，人們普遍的狂妄在於，總是認為自己所置身的環境正在發生著某種碾壓式的變革，但其實，最終大概率不過是一場平庸。

作者 | dog250

責編 | 劉靜

出品 | CSDN博客

但凡懂Linux內核的，都知道Linux內核的CFS進程調度演算法，無論是從2.6.23將其初引入時的論文，還是各類源碼分析，文章，以及Linux內核專門的圖書，都給人這樣一種感覺，即 CFS調度器是革命性的，它將徹底改變進程調度演算法。 預期中，人們期待它會帶來令人驚艷的效果。

然而這是錯覺。

人們希望CFS速勝，但是分析來分析去， 卻只是在某些方面比O(1)調度器稍微好一點點 。甚至在某些方面比不上古老的4.4BSD調度器。可是人們卻依然對其趨之若鶩，特別是源碼分析，汗牛塞屋！

為什麼CFS對別的調度演算法沒有帶來碾壓的效果呢？

首先，在真實世界，碾壓是不存在的，人與人，事與事既然被放在了同一個重量級梯隊比較，其之間的差別沒有想像的那麼大，根本就不在誰碾壓誰。不能被小說電視劇電影蒙蔽了，此外，徐曉冬大擺拳暴打雷雷也不算數，因為他們本就不是一個梯隊。

任何領域，革命性的碾壓式推陳出新並不是沒有，但是概率極低，人們普遍的狂妄在於，總是認為自己所置身的環境正在發生著某種碾壓式的變革，但其實，最終大概率不過是一場平庸。

最終就出現了角力，僵持。

其次，我們應該看到，CFS調度器聲稱它會給互動式進程帶來福音，在這方面CFS確實比O(1)做得好，但是驚艷的效果來自於粉絲的認同。Linux系統交互進程本來就不多，Linux更多地被裝在伺服器，而在伺服器看來，吞吐是要比交互響應更加重要的。

那麼以交互為主的Android系統呢？我們知道，Android也是採用了CFS調度器，也有一些事BFS，為什麼同樣沒有帶來驚艷的效果呢？

我承認，2008年前後出現CFS時還沒有Android，等到Android出現時，其採用的Linux內核已經默認了CFS調度器，我們看下Android版本，Linux內核版本以及發行時間的關系：

Linux內核在2.6.23就採用了CFS調度器。所以一個原因就是沒有比較。Android系統上，CFS沒有機會和O(1)做比較。

另外，即便回移一個O(1)調度器到Android系統去和CFS做AB，在我看來，CFS同樣不會驚艷，原因很簡單，Android系統幾乎都是交互進程，卻前台進程永遠只有一個，你幾乎感受不到進程的切換卡頓，換句話說，即便CFS對待互動式進程比O(1)好太多，你也感受不到，因為對於手機，平板而言，你切換 APP 的時間遠遠大於進程切換的時間粒度。

那麼，CFS到底好在哪裡？

簡單點說，CFS的意義在於， 在一個混雜著大量計算型進程和IO交互進程的系統中，CFS調度器對待IO交互進程要比O(1)調度器更加友善和公平 。理解這一點至關重要。

其實，CFS調度器的理念非常古老，就說在業界，CFS的思想早就被應用在了磁碟IO調度，數據包調度等領域，甚至最最古老的SRV3以及4.3BSD UNIX系統的進程調度中早就有了CFS的身影，可以說，Linux只是 使用CFS調度器 ，而不是 設計了CFS調度器 ！

就以4.3BSD調度器為例，我們看一下其調度原理。

4.3BSD採用了1秒搶占制，每間隔1秒，會對整個系統進程進行優先順序排序，然後找到優先順序最高的投入運行，非常簡單的一個思想，現在看看它是如何計算優先順序的。

首先，每一個進程j均擁有一個CPU滴答的度量值Cj，每一個時鍾滴答，當前在運行的進程的CPU度量值C會遞增：

當一個1秒的時間區間ii過去之後，Cj被重置，該進程jj的優先順序採用下面的公式計算：

可以計算，在一個足夠長的時間段內，兩個進程運行的總時間比例，將和它們的Base_PrioBase_Prio優先順序的比例相等。

4.3BSD的優先順序公平調度是CPU滴答驅動的。

現在看Linux的CFS，CFS採用隨時搶占制。每一個進程j均攜帶一個 虛擬時鍾VCj ，每一個時鍾滴答，當前進程k的VCk會重新計算，同時調度器選擇VC最小的進程運行，計算方法非常簡單：

可見， Linux的CFS簡直就是4.3BSD進程調度的自驅無級變速版本！

如果你想了解CFS的精髓，上面的就是了。換成語言描述，CFS的精髓就是 「 n個進程的系統，任意長的時間周期TT，每一個進程運行T/n的時間！ 」

當然，在現實和實現中，會有80%的代碼處理20%的剩餘問題，比如如何獎勵睡眠太久的進程等等，但是這些都不是精髓。

綜上，我們總結了：

所以無論從概念還是從效果，Linux CFS調度器均沒有帶來令人眼前一亮的哇塞效果。但是還缺點什麼。嗯，技術上的解釋。

分析和解釋任何一個機制之前，必然要先問，這個機制的目標是什麼，它要解決什麼問題，這樣才有意義。而不能僅僅是明白了它是怎麼工作的。

那麼Linux CFS調度器被採用，它的目標是解決什麼問題的呢？它肯定是針對O(1)演算法的一個問題而被引入並取代O(1)，該問題也許並非什麼臭名昭著，但是確實是一枚釘子，必須拔除。

O(1)調度器的本質問題在於 進程的優先順序和進程可運行的時間片進行了強映射！

也就是說，給定一個進程優先順序，就會計算出一個時間片與之對應，我們忽略獎懲相關的動態優先順序，看一下原始O(1)演算法中一個進程時間片的計算：

直觀點顯示：

針對上述問題，2.6內核的O(1)O(1)引入了雙斜率來解決：

直觀圖示如下：

貌似問題解決了，但是如果單單揪住上圖的某一個優先順序子區間來看，還是會有問題，這就是相對優先順序的問題。我們看到，高優先順序的時間片是緩慢增減的，而低優先順序的時間片卻是陡然增減，同樣都是相差同樣優先順序的進程，其優先順序分布影響了它們的時間片分配。

本來是治瘸子，結果腿好了，但是胳臂壞了。

本質上來講，這都源自於下面兩個原因：

固定的優先順序映射到固定的時間片。

相對優先順序和絕對優先順序混雜。

那麼這個問題如何解決？

優先順序和時間片本來就是兩個概念，二者中間還得有個變數溝通才可以。優先順序高只是說明該進程能運行的久一些，但是到底久多少，並不是僅僅優先順序就能決定的，還要綜合考慮，換句話距離來說，如果只有一個進程，那麼即便它優先順序再低，它也可以永久運行，如果系統中有很多的進程，即便再高優先順序的進程也要讓出一些時間給其它進程。

所以，考慮到系統中總體的進程情況，將優先順序轉換為權重，將時間片轉換為份額，CFS就是了。最終的坐標系應該是 權重佔比/時間片 坐標系而不是 權重(或者優先順序)/時間片 。應該是這個平滑的樣子：

看來，Linux CFS只是為了解決O(1)O(1)中一個 「靜態優先順序/時間片映射」 問題的，那麼可想而知，它又能帶來什麼驚艷效果呢？這里還有個「但是」，這個O(1)O(1)調度器的問題其實在計算密集型的守護進程看來，並不是問題，反而是好事，畢竟高優先順序進程可以 無條件持續運行很久而不切換 。這對於吞吐率的提高，cache利用都是有好處的。無非也就侵擾了交互進程唄，又有何妨。

當然，使用調優CFS的時候，難免也要遇到IO睡眠獎懲等剩餘的事情去設計一些trick演算法，這破費精力。

對了，還要設置你的內核為HZ1000哦，這樣更能體現CFS的平滑性，就像它宣稱的那樣。我難以想像，出了Ubuntu，Suse等花哨的桌面發行版之外，還有哪個Linux需要打開HZ1000，伺服器用HZ250不挺好嗎？

關於調度的話題基本就說完了，但是在進入下一步固有的噴子環節之前，還有兩點要強調：

在CPU核數越來越多的時代，人們更應該關心 把進程調度到哪裡CPU核上 而不是 某個CPU核要運行哪個進程 。

單核時代一路走過來的Linux，發展迅猛，這無可厚非，但是成就一個操作系統內核的並不單單是技術，還有別的。這些當然程序員們很不愛聽，程序員最煩非技術方面的東西了，程序員跟誰都比寫代碼，程序員特別喜歡噴領導不會寫代碼雲雲。

Linux在純技術方面並不優秀，Linux總體上優秀的原因是因為有一群非代碼不明志的程序員在讓它變得越來越優秀，另一方面還要歸功於開源和社區。Linux的學習門檻極低，如果一個公司能不費吹灰之力招聘到一個Linux程序員的話，那它幹嘛還要費勁九牛二虎之力去招聘什麼高端的BSD程序員呢？最終的結果就是，Linux用的人極多，想換也換不掉了。

但無論如何也沒法彌補Linux內核上的一些原則性錯誤。

Linux內核還是以原始的主線為base，以講Linux內核的書為例，經典的Robert Love的《Linux內核設計與實現》，以及《深入理解Linux內核》，在講進程調度的時候，關於多核負載均衡的筆墨都是少之又少甚至沒有，如此經典的著作把很多同好引向了那萬劫不復的代碼深淵。於是乎，鋪天蓋地的CFS源碼分析紛至沓來。

但其實，拋開這么一個再普通不過的Linux內核，現代操作系統進入了多核時代，其核心正是在cache利用上的革新，帶來的轉變就是進程調度和內存管理的革新。review一下Linux內核源碼，這些改變早就已經表現了出來。

可悲的是，關於Linux內核的經典書籍卻再也沒有更新，所有的從傳統學校出來的喜歡看書學習的，依然是抱著10年前的大部頭在啃。

http :// www. ece.ubc.ca/~sasha/papers/eurosys16-final29.pdf

浙江溫州皮鞋濕，下雨進水不會胖。

作者：CSDN博主「dog250」，本文首發於作者CSDN博客https://blog.csdn.net/dog250/article/details/957298 30 。

【END】

Ⅳ 如何編寫Linux 驅動程序

如何編寫Linux設備驅動程序
回想學習Linux操作系統已經有近一年的時間了，前前後後，零零碎碎的一路學習過來，也該試著寫的東西了。也算是給自己能留下一點記憶和回憶吧！由於完全是自學的，以下內容若有不當之處，還請大家多指教。
Linux是Unix操作系統的一種變種，在Linux下編寫驅動程序的原理和思想完全類似於其他的Unix系統，但它dos或window環境下的驅動程序有很大的區別。在Linux環境下設計驅動程序，思想簡潔，操作方便，功能也很強大，但是支持函數少，只能依賴kernel中的函數，有些常用的操作要自己來編寫，而且調試也不方便。
以下的一些文字主要來源於khg，johnsonm的Write linux device driver，Brennan's Guide to Inline Assembly，The Linux A-Z，還有清華BBS上的有關device driver的一些資料。
一、Linux device driver 的概念
系統調用是操作系統內核和應用程序之間的介面，設備驅動程序是操作系統內核和機器硬體之間的介面。設備驅動程序為應用程序屏蔽了硬體的細節，這樣在應用程序看來，硬體設備只是一個設備文件，應用程序可以象操作普通文件一樣對硬體設備進行操作。設備驅動程序是內核的一部分，它完成以下的功能:
1、對設備初始化和釋放。
2、把數據從內核傳送到硬體和從硬體讀取數據。
3、讀取應用程序傳送給設備文件的數據和回送應用程序請求的數據。
4、檢測和處理設備出現的錯誤。
在Linux操作系統下有三類主要的設備文件類型，一是字元設備，二是塊設備，三是網路設備。字元設備和塊設備的主要區別是:在對字元設備發出讀/寫請求時，實際的硬體I/O一般就緊接著發生了，塊設備則不然，它利用一塊系統內存作緩沖區，當用戶進程對設備請求能滿足用戶的要求，就返回請求的數據，如果不能，就調用請求函數來進行實際的I/O操作。塊設備是主要針對磁碟等慢速設備設計的，以免耗費過多的CPU時間來等待。
已經提到，用戶進程是通過設備文件來與實際的硬體打交道。每個設備文件都都有其文件屬性(c/b)，表示是字元設備還是塊設備?另外每個文件都有兩個設備號，第一個是主設備號，標識驅動程序，第二個是從設備號，標識使用同一個設備驅動程序的不同的硬體設備，比如有兩個軟盤，就可以用從設備號來區分他們。設備文件的的主設備號必須與設備驅動程序在登記時申請的主設備號一致，否則用戶進程將無法訪問到驅動程序。
最後必須提到的是，在用戶進程調用驅動程序時，系統進入核心態，這時不再是搶先式調度。也就是說，系統必須在你的驅動程序的子函數返回後才能進行其他的工作。如果你的驅動程序陷入死循環，不幸的是你只有重新啟動機器了，然後就是漫長的fsck。
讀/寫時，它首先察看緩沖區的內容，如果緩沖區的數據未被處理，則先處理其中的內容。
如何編寫Linux操作系統下的設備驅動程序

二、實例剖析
我們來寫一個最簡單的字元設備驅動程序。雖然它什麼也不做，但是通過它可以了解Linux的設備驅動程序的工作原理。把下面的C代碼輸入機器，你就會獲得一個真正的設備驅動程序。
#define __NO_VERSION__
#include <linux/moles.h>
#include <linux/version.h>
char kernel_version [] = UTS_RELEASE;
這一段定義了一些版本信息，雖然用處不是很大，但也必不可少。Johnsonm說所有的驅動程序的開頭都要包含<linux/config.h>，一般來講最好使用。
由於用戶進程是通過設備文件同硬體打交道，對設備文件的操作方式不外乎就是一些系統調用，如 open，read，write，close…， 注意，不是fopen， fread，但是如何把系統調用和驅動程序關聯起來呢?這需要了解一個非常關鍵的數據結構：
struct file_operations
{
int (*seek) (struct inode * ，struct file *， off_t ，int);
int (*read) (struct inode * ，struct file *， char ，int);
int (*write) (struct inode * ，struct file *， off_t ，int);
int (*readdir) (struct inode * ，struct file *， struct dirent * ，int);
int (*select) (struct inode * ，struct file *， int ，select_table *);
int (*ioctl) (struct inode * ，struct file *， unsined int ，unsigned long);
int (*mmap) (struct inode * ，struct file *， struct vm_area_struct *);
int (*open) (struct inode * ，struct file *);
int (*release) (struct inode * ，struct file *);
int (*fsync) (struct inode * ，struct file *);
int (*fasync) (struct inode * ，struct file *，int);
int (*check_media_change) (struct inode * ，struct file *);
int (*revalidate) (dev_t dev);
}

這個結構的每一個成員的名字都對應著一個系統調用。用戶進程利用系統調用在對設備文件進行諸如read/write操作時，系統調用通過設備文件的主設備號找到相應的設備驅動程序，然後讀取這個數據結構相應的函數指針，接著把控制權交給該函數。這是linux的設備驅動程序工作的基本原理。既然是這樣，則編寫設備驅動程序的主要工作就是編寫子函數，並填充file_operations的各個域。
下面就開始寫子程序。
#include <linux/types.h>
#include <linux/fs.h>
#include <linux/mm.h>
#include<linux/config.h>
#include <linux/errno.h>
#include <asm/segment.h>
unsigned int test_major = 0;
static int read_test(struct inode *node，struct file *file，char *buf，int count)
{
int left;
if (verify_area(VERIFY_WRITE，buf，count) == -EFAULT )
return -EFAULT;
for(left = count ; left > 0 ; left--)
{
__put_user(1，buf，1);
buf++;
}
return count;
}

這個函數是為read調用准備的。當調用read時，read_test()被調用，它把用戶的緩沖區全部寫1。buf 是read調用的一個參數。它是用戶進程空間的一個地址。但是在read_test被調用時，系統進入核心態。所以不能使用buf這個地址，必須用__put_user()，這是kernel提供的一個函數，用於向用戶傳送數據。另外還有很多類似功能的函數。請參考Robert著的《Linux內核設計與實現》（第二版）。然而，在向用戶空間拷貝數據之前，必須驗證buf是否可用。這就用到函數verify_area。
static int write_tibet(struct inode *inode，struct file *file，const char *buf，int count)
{
return count;
}
static int open_tibet(struct inode *inode，struct file *file )
{
MOD_INC_USE_COUNT;
return 0;
}
static void release_tibet(struct inode *inode，struct file *file )
{
MOD_DEC_USE_COUNT;
}

這幾個函數都是空操作。實際調用發生時什麼也不做，他們僅僅為下面的結構提供函數指針。
struct file_operations test_fops = {
NULL，
read_test，
write_test，
NULL， /* test_readdir */
NULL，
NULL， /* test_ioctl */
NULL， /* test_mmap */
open_test，
release_test，
NULL， /* test_fsync */
NULL， /* test_fasync */
/* nothing more， fill with NULLs */
};
這樣，設備驅動程序的主體可以說是寫好了。現在要把驅動程序嵌入內核。驅動程序可以按照兩種方式編譯。一種是編譯進kernel，另一種是編譯成模塊(moles)，如果編譯進內核的話，會增加內核的大小，還要改動內核的源文件，而且不能動態的卸載，不利於調試，所以推薦使用模塊方式。
int init_mole(void)
{
int result;
result = register_chrdev(0， "test"， &test_fops);
if (result < 0) {
printk(KERN_INFO "test: can't get major number\n");
return result;
}
if (test_major == 0) test_major = result; /* dynamic */
return 0;
}

在用insmod命令將編譯好的模塊調入內存時，init_mole 函數被調用。在這里，init_mole只做了一件事，就是向系統的字元設備表登記了一個字元設備。register_chrdev需要三個參數，參數一是希望獲得的設備號，如果是零的話，系統將選擇一個沒有被佔用的設備號返回。參數二是設備文件名，參數三用來登記驅動程序實際執行操作的函數的指針。
如果登記成功，返回設備的主設備號，不成功，返回一個負值。
void cleanup_mole(void)
{
unregister_chrdev(test_major，"test");
}
在用rmmod卸載模塊時，cleanup_mole函數被調用，它釋放字元設備test在系統字元設備表中佔有的表項。
一個極其簡單的字元設備可以說寫好了，文件名就叫test.c吧。
下面編譯 :
$ gcc -O2 -DMODULE -D__KERNEL__ -c test.c
得到文件test.o就是一個設備驅動程序。
如果設備驅動程序有多個文件，把每個文件按上面的命令行編譯，然後
ld -r file1.o file2.o -o molename。
驅動程序已經編譯好了，現在把它安裝到系統中去。
$ insmod –f test.o
如果安裝成功，在/proc/devices文件中就可以看到設備test，並可以看到它的主設備號。要卸載的話，運行 :
$ rmmod test
下一步要創建設備文件。
mknod /dev/test c major minor
c 是指字元設備，major是主設備號，就是在/proc/devices里看到的。
用shell命令
$ cat /proc/devices
就可以獲得主設備號，可以把上面的命令行加入你的shell script中去。
minor是從設備號，設置成0就可以了。
我們現在可以通過設備文件來訪問我們的驅動程序。寫一個小小的測試程序。
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
main()
{
int testdev;
int i;
char buf[10];
testdev = open("/dev/test"，O_RDWR);
if ( testdev == -1 )
{
printf("Cann't open file \n");
exit(0);
}
read(testdev，buf，10);
for (i = 0; i < 10;i++)
printf("%d\n"，buf[i]);
close(testdev);
}

編譯運行，看看是不是列印出全1 ？
以上只是一個簡單的演示。真正實用的驅動程序要復雜的多，要處理如中斷，DMA，I/O port等問題。這些才是真正的難點。請看下節，實際情況的處理。
如何編寫Linux操作系統下的設備驅動程序
三、設備驅動程序中的一些具體問題
1。 I/O Port。
和硬體打交道離不開I/O Port，老的ISA設備經常是佔用實際的I/O埠，在linux下，操作系統沒有對I/O口屏蔽，也就是說，任何驅動程序都可對任意的I/O口操作，這樣就很容易引起混亂。每個驅動程序應該自己避免誤用埠。
有兩個重要的kernel函數可以保證驅動程序做到這一點。
1）check_region(int io_port， int off_set)
這個函數察看系統的I/O表，看是否有別的驅動程序佔用某一段I/O口。
參數1：I/O埠的基地址，
參數2：I/O埠佔用的范圍。
返回值：0 沒有佔用， 非0，已經被佔用。
2）request_region(int io_port， int off_set，char *devname)
如果這段I/O埠沒有被佔用，在我們的驅動程序中就可以使用它。在使用之前，必須向系統登記，以防止被其他程序佔用。登記後，在/proc/ioports文件中可以看到你登記的I/O口。
參數1：io埠的基地址。
參數2：io埠佔用的范圍。
參數3：使用這段io地址的設備名。
在對I/O口登記後，就可以放心地用inb()， outb()之類的函來訪問了。
在一些pci設備中，I/O埠被映射到一段內存中去，要訪問這些埠就相當於訪問一段內存。經常性的，我們要獲得一塊內存的物理地址。

2。內存操作
在設備驅動程序中動態開辟內存，不是用malloc，而是kmalloc，或者用get_free_pages直接申請頁。釋放內存用的是kfree，或free_pages。 請注意，kmalloc等函數返回的是物理地址！
注意，kmalloc最大隻能開辟128k-16，16個位元組是被頁描述符結構佔用了。
內存映射的I/O口，寄存器或者是硬體設備的RAM(如顯存)一般佔用F0000000以上的地址空間。在驅動程序中不能直接訪問，要通過kernel函數vremap獲得重新映射以後的地址。
另外，很多硬體需要一塊比較大的連續內存用作DMA傳送。這塊程序需要一直駐留在內存，不能被交換到文件中去。但是kmalloc最多隻能開辟128k的內存。
這可以通過犧牲一些系統內存的方法來解決。

3。中斷處理
同處理I/O埠一樣，要使用一個中斷，必須先向系統登記。
int request_irq(unsigned int irq ，void(*handle)(int，void *，struct pt_regs *)，
unsigned int long flags， const char *device);
irq: 是要申請的中斷。
handle：中斷處理函數指針。
flags：SA_INTERRUPT 請求一個快速中斷，0 正常中斷。
device：設備名。

如果登記成功，返回0，這時在/proc/interrupts文件中可以看你請求的中斷。
4。一些常見的問題。
對硬體操作，有時時序很重要（關於時序的具體問題就要參考具體的設備晶元手冊啦！比如網卡晶元RTL8139）。但是如果用C語言寫一些低級的硬體操作的話，gcc往往會對你的程序進行優化，這樣時序會發生錯誤。如果用匯編寫呢，gcc同樣會對匯編代碼進行優化，除非用volatile關鍵字修飾。最保險的辦法是禁止優化。這當然只能對一部分你自己編寫的代碼。如果對所有的代碼都不優化，你會發現驅動程序根本無法裝載。這是因為在編譯驅動程序時要用到gcc的一些擴展特性，而這些擴展特性必須在加了優化選項之後才能體現出來。
寫在後面：學習Linux確實不是一件容易的事情，因為要付出很多精力，也必須具備很好的C語言基礎；但是，學習Linux也是一件非常有趣的事情，它裡麵包含了許多高手的智慧和「幽默」，這些都需要自己親自動手才能體會到，O(∩_∩)O~哈哈！

Ⅵ 操作系統是演算法嗎

操作系統不是演算法。演算法的定義是有規范的輸入，在一定有限時間內獲得所要求的輸出的指令的集合。從定義看它與操作系統是兩個概念，當然具體到操作系統本身來說是由很多不同的演算法來執行，比如說磁碟調度演算法、進程調度演算法等等。
操作系統（Operating System，簡稱OS）是管理和控制計算機硬體與軟體資源的計算機程序，是直接運行在「裸機」上的最基本的系統軟體，任何其他軟體都必須在操作系統的支持下才能運行。
操作系統是用戶和計算機的介面，同時也是計算機硬體和其他軟體的介面。操作系統的功能包括管理計算機系統的硬體、軟體及數據資源，控製程序運行，改善人機界面，為其它應用軟體提供支持，讓計算機系統所有資源最大限度地發揮作用，提供各種形式的用戶界面，使用戶有一個好的工作環境，為其它軟體的開發提供必要的服務和相應的介面等。實際上，用戶是不用接觸操作系統的，操作系統管理著計算機硬體資源，同時按照應用程序的資源請求，分配資源，如：劃分CPU時間，內存空間的開辟，調用列印機等。

Ⅶ Linux內核是什麼

Linux內核無疑是Linux操作系統的核心。它由以下五個子系統構成
（1）進程調度
（2）內存管理
（3）虛擬文件系統
（4）網路介面
（5）進程之間的通信

Ⅷ linux 管道原理

Linux原理的學習，我打算由淺入深，從上之下，也就是先了解個大概再逐個深入。先了解一下Linux的進程先。

一、Linux進程上下文

Linux進程上下文，我理解就是進程組成元素的集合。包括進程描述符tast_struct，正文段，數據段，棧，寄存器內容，頁表等。

1）tast_struct

它是一種數據結構，存儲著進程的描述信息，例如pid，uid，狀態，信號項，打開文件表等。是進程管理和調度的重要依據。

2）用戶棧和核心棧

顧名思義，用戶棧是進程運行在用戶態使用的棧，含有用戶態執行時候函數調用的參數，局部變數等；核心棧是該進程運行在核心態下用的棧，保存調用系統函數所用的參數和調用序列。這兩個棧的指針都保存在tast_struct結構中。

3）寄存器

保存程序計數器，狀態字，通用寄存器，棧指針。

4）頁表

線性地址到物理地址的映射

5）正文段，數據段。

二、Linux進程的狀態

Linux中進程共有5個狀態：就緒，可中斷睡眠，不可中斷睡眠，暫停，僵死。也就是說，linux不區分就緒和運行，它們統一叫做就緒態。進程所處的狀態記錄在tast_struct中。

三、進程的控制

1）進程樹的形成

計算機啟動後，BIOS從磁碟引導扇區載入系統引導程序，它將Linux系統裝入內存，並跳到內核處執行，Linux內核就執行初始化工作：初始化硬體、初始化內部數據結構、建立進程0。進程0創建進程1，進程1是以後所有創建的進程的祖先，它負責初始化所有的用戶進程。進程1創建shell進程，shell進程顯示提示符，等待命令的輸入。

2）進程的創建

任何一個用戶進程的創建都是由現有的一個進程完成的，進程的創建要經過fork和exec兩個過程。Fork是為新進程分配相應的數據結構，並將父進程的相應上下文信息復制過來。Exec是將可執行文件的正文和數據轉入內存覆蓋它原來的（從父進程復制過來的），並開始執行正文段。

3）進程的終止

系統調用exit()就可自我終結，exit釋放除了tast_struct以外的所有上下文，父進程收到子進程終結的消息後，釋放子進程的tast_struct。

4）進程的調度

進程的調度是由schele()完成的，一種情況是，當處理機從核心態向用戶態轉換之前，它會檢查調度標志是否為1，如果是1，則運行schele()，執行進程的調度。另一種情況是進程自動放棄處理機，時候進行進程調度。

進程的調度過程分為兩步，首先利用相關策略選擇要執行的進程，然後進行上下文的切換。

四、進程的通信

進程的通信策略主要有，消息，管道，消息隊列，共享存儲區和信號量。

1）信息

消息機制主要是用來傳遞進程間的軟中斷信號，通知對方發生了非同步事件。發送進程將信號（約定好的符號）發送到目標進程的tast_struct中的信號項，接收進程看到有消息後就調用相應的處理程序，注意，處理程序必須到進程執行時候才能執行，不能立即響應。

2）管道

我理解就是兩個進程使用告訴緩沖區中的一個隊列（每兩個進程一個），發送進程將數據發送到管道入口，接收進程從管道出口讀數據。

3） 消息隊列

消息隊列是操作系統維護的一個個消息鏈表，發送進程根據消息標識符將消息添加到制定隊列中，接收進程從中讀取消息。

4）共享存儲區

在內存中開辟一個區域，是個進程共享的，也就是說進程可以把它附加到自己的地址空間中，對此區域中的數據進行操作。

5）信號量

控制進程的同步。