嵌入式linux内存使用和性能优化
這本書有兩個關切點：系統內存(用戶層)和性能優化。
這本書和Brendan Gregg的《Systems Performance》相比，無論是技術層次還是更高的理論都有較大差距。但是這不影響，快速花點時間簡單過一遍。
然后在對《Systems Performance》進行詳細的學習。
由于Ubuntu測試驗證更合適，所以在Ubuntu(16.04)+Kernel(4.10.0)環境下做了下面的實驗。
?
全書共9章：1~4章著重于內存的使用，盡量降低進程的內存使用量，定位和發現內存泄露；5~9章著重于如何讓系統性能優化，提高執行速度。
第1章 內存的測量
第2章 進程內存優化
第3章 系統內存優化
第4章 內存泄露
第5章 性能優化的流程
第6章 進程啟動速度
第7章 性能優化的方法
第8章 代碼優化的境界
第9章 系統性能優化
用戶空間的內存使用量是由進程使用量累積和系統使用之和，所以優化系統內存使用，就是逐個攻克每個進程的使用量和優化系統內存使用。。
俗話說“知己知彼，百戰不殆”，要優化一個進程的使用量，首先得使用工具去評估內存使用量(第1章 內存的測量)；
然后就來看看進程那些部分耗費內存，并針對性進行優化(第2章 進程內存優化)；
最后從系統層面尋找方法進行優化(第3章 系統內存優化)。
內存的使用一個致命點就是內存泄露，如何發現內存泄露，并且將內存泄露定位是重點(第4章 內存泄露)
第1章 內存的測量
作者在開頭的一段話說明了本書采用的方法論：
關于系統內存使用，將按照(1)明確目標->(2)尋找評估方法，(3)了解當前狀況->對系統內存進行優化->重新測量，評估改善狀況的過程，來闡述系統的內存使用與優化。
(1)明確目標，針對系統內存優化，有兩個：
? A.每個守護進程使用的內存盡可能少
? B.長時間運行后，守護進程內存仍然保持較低使用量，沒有內存泄露。
(2)尋找評估方法，第1章關注點。
(3)對系統內存進行優化，第2章針對進程進行優化，第3章針對系統層面進行內存優化，第4章關注內存泄露。
系統內存測量
free用以獲得當前系統內存使用情況。
在一嵌入式設備獲取如下：
| busybox free |
和PC使用的free對比：
| ???????????? total?????? used?????? free???? shared??? buffers???? cached |
可見這兩個命令存在差異，busybox沒有cached。這和實際不符，實際可用內存=free+buffers+cached。
buffers是用來給Linux系統中塊設備做緩沖區，cached用來緩沖打開的文件。下面是通過cat /proc/meminfo獲取，可知實際可用內存=8352+0+3508=11860。已經使用內存為=23940-11860=12080。可見兩者存在差異，busybox的free不太準確；/proc/meminfo的數據更準確。
| MemTotal:????????? 23940 kB |
進程內存測量
在進程的proc中與內存有關的節點有statm、maps、memmap。
cat /proc/xxx/statm
| 1086 168 148 1 0 83 0 |
這些參數以頁(4K)為單位，分別是：
1086 Size，任務虛擬地址空間的大小。
168 Resident，應用程序正在使用的物理內存的大小。
148 Shared，共享頁數。
1 Trs，程序所擁有的可執行虛擬內存的大小。
0 Lrs，被映像到任務的虛擬內存空間的的庫的大小。
83 Drs，程序數據段和用戶態的棧的大小。
0 dt，臟頁數量(已經修改的物理頁面)。
Size、Trs、Lrs、Drs對應虛擬內存，Resident、Shared、dt對應物理內存。
cat /proc/xxx/maps
| 00400000-00401000 r-xp 00000000 08:05 18561374?????????????????????????? /home/lubaoquan/temp/hello |
第一列，代表該內存段的虛擬地址。
第二列，r-xp，代表該段內存的權限，r=讀，w=寫，x=執行，s=共享，p=私有。
第三列，代表在進程地址里的偏移量。
第四列，映射文件的的主從設備號。
第五列，映像文件的節點號。
第六列，映像文件的路徑。
kswapd
Linux存在一個守護進程kswapd，他是Linux內存回收機制，會定期監察系統中空閑呢村的數量，一旦發現空閑內存數量小于一個閾值的時候，就會將若干頁面換出。
但是在嵌入式Linux系統中，卻沒有交換分區。沒有交換分區的原因是：
1.一旦使用了交換分區，系統系能將下降的很快，不可接受。
2.Flash的寫次數是有限的，如果在Flash上面建立交換分區，必然導致對Flash的頻繁讀寫，影響Flash壽命。
那沒有交換分區，Linux是如何做內存回收的呢？
對于那些沒有被改寫的頁面，這塊內存不需要寫到交換分區上，可以直接回收。
對于已經改寫了的頁面，只能保留在系統中，，沒有交換分區，不能寫到Flash上。
在Linux物理內存中，每個頁面有一個dirty標志，如果被改寫了，稱之為dirty page。所有非dirty page都可以被回收。
?
第2章 進程內存優化
當存在很多守護進程，又要去降低守護進程內存占用量，如何去推動：
1.所有守護進程內存只能比上一個版本變少。
2.Dirty Page排前10的守護進程，努力去優化，dirty page減少20%。
可以從三個方面去優化：
1.執行文件所占用的內存
2.動態庫對內存的影響
3.線程對內存的影響
2.1 執行文件
一個程序包括代碼段、數據段、堆段和棧段。一個進程運行時，所占用的內存，可以分為如下幾部分：
棧區(stack)：由編譯器自動分配釋放，存放函數的參數、局部變量等
堆區(heap)：一般由程序員分配釋放，若程序員不釋放，程序結束時可有操作系統來回收
全局變量、靜態變量：初始化的全局變量和靜態變量在一塊區域，未初始化的全局變量和靜態變量在另一塊區域，程序結束后由系統釋放
文字常量：常量、字符串就是放在這里的，程序結束后有系統釋放
程序代碼：存放函數體的二進制代碼
下面結合一個實例分析：
| #include <stdlib.h> int n=10; int main() ? printf("pid:%d\n", pid); |
執行程序結果：
| pid:18768 |
查看cat /proc/17868/maps
| 00400000-00401000 r-xp 00000000 08:05 18561376?????????????????????????? /home/lubaoquan/temp/example |
?
第3章 系統內存優化
3.1 守護進程的內存使用
守護進程由于上期運行，對系統內存使用影響很大：
1.由于一直存貨，所以其占用的內存不會被釋放。
2.即使什么都不做，由于引用動態庫，也會占用大量的物理內存。
3.由于生存周期很長，哪怕一點內存泄露，累積下來也會很大，導致內存耗盡。
那么如何降低風險呢？
1.設計守護進程時，區分常駐部分和非常駐部分。盡量降低守護進程的邏輯，降低內存占用，降低內存泄露幾率。或者將幾個守護進程內容合為一個。
2.有些進程只是需要盡早啟動，而不需要變成守護進程。可以考慮加快啟動速度，從而使服務達到按需啟動的需求。優化方式有優化加載動態庫、使用Prelink方法、采用一些進程調度方法等。
3.2 tmpfs分區
Linux中為了加快文件讀寫，基于內存建立了一個文件系統，成為ramdisk或者tmpfs，文件訪問都是基于物理內存的。
使用df -k /tmp可以查看分區所占空間大小：
| Filesystem???? 1K-blocks??? Used Available Use% Mounted on |
在對這個分區進行讀寫時，要時刻注意，他是占用物理內存的。不需要的文件要及時刪除。
3.3 Cache和Buffer
系統空閑內存=MemFree+Buffers+Cached。
Cache也稱緩存，是把從Flash中讀取的數據保存起來，若再次讀取就不需要去讀Flash了，直接從緩存中讀取，從而提高讀取文件速度。Cache緩存的數據會根據讀取頻率進行組織，并最頻繁讀取的內容放在最容易找到的位置，把不再讀的內容不短往后排，直至從中刪除。
在程序執行過程中，發現某些指令不在內存中，便會產生page fault，將代碼載入到物理內存。程序退出后，代碼段內存不會立即丟棄，二是作為Cache緩存。
Buffer也稱緩存，是根據Flash讀寫設計的，把零散的寫操作集中進行，減少Flash寫的次數，從而提高系統性能。
Cache和BUffer區別簡單的說都是RAM中的數據，Buffer是即將寫入磁盤的，而Cache是從磁盤中讀取的。
使用free -m按M來顯示Cache和Buffer大小：
| ???????????? total?????? used?????? free???? shared??? buffers???? cached |
降低Cache和Buffer的方法：
sync
? 該命令將未寫的系統緩沖區寫到磁盤中。包含已修改的 i-node、已延遲的塊 I/O 和讀寫映射文件。/proc/sys/vm/drop_caches
? a）清理pagecache（頁面緩存）
?# echo 1 > /proc/sys/vm/drop_caches???? 或者 # sysctl -w vm.drop_caches=1
? b）清理dentries（目錄緩存）和inodes
?# echo 2 > /proc/sys/vm/drop_caches???? 或者 # sysctl -w vm.drop_caches=2c）清理pagecache、dentries和inodes
?
?# echo 3 > /proc/sys/vm/drop_caches???? 或者 # sysctl -w vm.drop_caches=3
? 上面三種方式都是臨時釋放緩存的方法，要想永久釋放緩存，需要在/etc/sysctl.conf文件中配置：vm.drop_caches=1/2/3，然后sysctl -p生效即可！
vfs_cache_pressurevfs_cache_pressure=100??? 這個是默認值，內核會嘗試重新聲明dentries和inodes，并采用一種相對于頁面緩存和交換緩存比較”合理”的比例。減少vfs_cache_pressure的值，會導致內核傾向于保留dentry和inode緩存。增加vfs_cache_pressure的值，（即超過100時），則會導致內核傾向于重新聲明dentries和inodes總之，vfs_cache_pressure的值：小于100的值不會導致緩存的大量減少超過100的值則會告訴內核你希望以高優先級來清理緩存。
3.4 內存回收
kswapd有兩個閾值：pages_high和pages_low，當空閑內存數量低于pages_low時，kswapd進程就會掃描內存并且每次釋放出32個free pages，知道free page數量達到pages_high。
kswapd回收內存的原則？
1.如果物理頁面不是dirty page，就將該物理頁面回收。
- 代碼段，只讀不能被改寫，所占內存都不是dirty page。
- 數據段，可讀寫，所占內存可能是dirty page，也可能不是。
- 堆段，沒有對應的映射文件，內容都是通過修改程序改寫的，所占物理內存都是dirty page。
- 棧段和堆段一樣，所占物理內存都是dirty page。
- 共享內存，所占物理內存都是dirty page。
就是說，這條規則主要面向進程的代碼段和未修改的數據段。
2.如果物理頁面已經修改并且可以備份回文件系統，就調用pdflush將內存中的內容和文件系統進行同步。pdflush寫回磁盤，主要針對Buffers。
3.如果物理頁面已經修改但是沒有任何磁盤的備份，就將其寫入swap分區。
kswapd再回首過程中還存在兩個重要方法：LMR(Low on Memory Reclaiming)和OMK(Out of Memory Killer)。
由于kswapd不能提供足夠空閑內存是，LMR將會起作用，每次釋放1024個垃圾頁知道內存分配成功。
當LMR不能快速釋放內存的時候，OMK就開始起作用，OMK會采用一個選擇算法來決定殺死某些進程。發送SIGKILL，就會立即釋放內存。
3.5 /proc/sys/vm優化
此文件夾下面有很多接口控制內存操作行為，在進行系統級內存優化的時候需要仔細研究，適當調整。
block_dump
? 表示是否打開Block Debug模式，用于記錄所有的讀寫及Dirty Block寫回操作。0，表示禁用Block Debug模式；1，表示開啟Block Debug模式。dirty_background_ratio
? 表示臟數據達到系統整體內存的百分比，此時觸發pdflush進程把臟數據寫回磁盤。dirty_expires_centisecs
? 表示臟數據在內存中駐留時間超過該值，pdflush進程在下一次將把這些數據寫回磁盤。缺省值3000，單位是1/100s。dirty_ratio
? 表示如果進程產生的臟數據達到系統整體內存的百分比，此時進程自行吧臟數據寫回磁盤。dirty_writeback_centisecs
? 表示pdflush進程周期性間隔多久把臟數據協會磁盤，單位是1/100s。vfs_cache_pressure
? 表示內核回收用于directory和inode cache內存的傾向；缺省值100表示內核將根據pagecache和swapcache，把directory和inode cache報紙在一個合理的百分比；降低該值低于100，將導致內核傾向于保留directory和inode cache；高于100，將導致內核傾向于回收directory和inode cache。min_free_kbytes
? 表示強制Linux VM最低保留多少空閑內存(KB)。nr_pdflush_threads
? 表示當前正在進行的pdflush進程數量，在I/O負載高的情況下，內核會自動增加更多的pdflush。overcommit_memory
? 指定了內核針對內存分配的策略，可以是0、1、2.
? 0 表示內核將檢查是否有足夠的可用內存供應用進程使用。如果足夠，內存申請允許；反之，內存申請失敗。
? 1 表示內核允許分配所有物理內存，而不管當前內存狀態如何。
? 2 表示內核允許分配查過所有物理內存和交換空間總和的內存。overcommit_ratio
? 如果overcommit_memory=2，可以過在內存的百分比。page-cluster
? 表示在寫一次到swap區時寫入的頁面數量，0表示1頁，3表示8頁。swapiness
? 表示系統進行交換行為的成都，數值(0~100)越高，越可能發生磁盤交換。legacy_va_layout
? 表示是否使用最新的32位共享內存mmap()系統調用。nr_hugepages
? 表示系統保留的hugetlg頁數。
?
第4章 內存泄露
4.1 如何確定是否有內存泄露
解決內存泄露一個好方法就是：不要讓你的進程成為一個守護進程，完成工作后立刻退出，Linux會自動回收該進程所占有的內存。
測試內存泄露的兩種方法：
1.模仿用戶長時間使用設備，查看內存使用情況，對于那些內存大量增長的進程，可以初步懷疑其有內存泄露。
2.針對某個具體測試用例，檢查是否有內存泄露。
在發現進程有漏洞之后，看看如何在代碼中檢查內存泄露。
4.2 mtrace
glibc針對內存泄露給出一個鉤子函數mtrace：
1.加入頭文件<mcheck.h>
2.在需要內存泄露檢查的代碼開始調用void mtrace()，在需要內存泄露檢查代碼結尾調用void muntrace()。如果不調用muntrace，程序自然結束后也會顯示內存泄露
3.用debug模式編譯檢查代碼(-g或-ggdb)
4.在運行程序前，先設置環境變量MALLOC_TRACE為一個文件名，這一文件將存有內存分配信息
5.運行程序，內存分配的log將輸出到MALLOC_TRACE所執行的文件中。
代碼如下：
| #include <stdio.h> int main(void) ? char *p=malloc(10); |
編譯，設置環境變量，執行，查看log：
| gcc -o mem-leakage -g mem-leakage.c export MALLOC_TRACE=/home/lubaoquan/temp/malloc.og ./mem-leakage ? = Start |
加入mtrace會導致程序運行緩慢：
1.日志需要寫到Flash上(可以將MALLOC_TRACE顯示到stdout上。)
2.mtrace函數內，試圖根據調用malloc代碼指針，解析出對應的函數
?
?
性能優化是一個艱苦、持續、枯燥、反復的過程，涉及到的內容非常多，編譯器優化、硬件體系結構、軟件的各種技巧等等。
另外在嵌入式電池供電系統上，性能的優化也要考慮到功耗的使能。PnP的兩個P(Power and Performance)是不可分割的部分。
?
第5章 性能優化的流程
5.1 性能評價
首先“快”與“慢”需要一個客觀的指標，同時明確定義測試階段的起訖點。
同時優化也要考慮到可移植性以及普適性，不要因為優化過度導致其他問題的出現。
5.2 性能優化的流程
1. 測量，獲得數據，知道和目標性能指標的差距。
2. 分析待優化的程序，查找性能瓶頸。
3. 修改程序。
4. 重新測試，驗證優化結果。
5. 達到性能要求，停止優化。不達目標，繼續分析。
?
5.3 性能評測?
介紹兩種方法：可視操作(攝像頭)和日志。
話說攝像頭錄像評測，還是很奇葩的，適用范圍很窄。但是貌似還是有一定市場。
5.4 性能分析
導致性能低下的三種主要原因：
(1) 程序運算量很大，消耗過多CPU指令。
(2) 程序需要大量I/O，讀寫文件、內存操作等，CPU更多處于I/O等待。
(3) 程序之間相互等待，結果CPU利用率很低。
簡單來說即是CPU利用率高、I/O等待時間長、死鎖情況。
下面重點放在第一種情況，提供三種方法。
1. 系統相關：/proc/stat、/proc/loadavg
cat /proc/stat結果如下：
cpu 12311503 48889 7259266 561072284 575332 0 72910 0 0 0-----分別是user、nice、system、idle、iowait、irq、softirq、steal、guest、guest_niceuser：從系統啟動開始累計到當前時刻，用戶態CPU時間，不包含nice值為負的進程。nice：從系統啟動開始累計到當前時刻，nice值為負的進程所占用的CPU時間。system：從系統啟動開始累計到當前時刻，內核所占用的CPU時間。idle：從系統啟動開始累計到當前時刻，除硬盤IO等待時間以外其他等待時間。iowait：從系統啟動開始累計到當前時刻，硬盤IO等待時間。irq：從系統啟動開始累計到當前時刻，硬中斷時間。softirq：從系統啟動開始累計到當前時刻，軟中斷時間。steal：從系統啟動開始累計到當前時刻，involuntary waitguest：running as a normal guestguest_nice：running as a niced guest
cpu0 3046879 11947 1729621 211387242 95062 0 1035 0 0 0 cpu1 3132086 8784 1788117 116767388 60010 0 535 0 0 0 cpu2 3240058 12964 1826822 116269699 353944 0 31989 0 0 0 cpu3 2892479 15192 1914705 116647954 66316 0 39349 0 0 0 intr 481552135 16 183 0 0 0 0 0 0 175524 37 0 0 2488 0 0 0 249 23 0 0 0 0 0 301 0 0 3499749 21 1470158 156 33589268 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -------------------Counts of interrupts services since boot time.Fist column is the total of all interrupts services, each subsequent if total for particular interrupt. ctxt 2345712926-------------------------------------------------Toal number of context switches performed since bootup accross all CPUs. btime 1510217813------------------------------------------------Give the time at which the system booted, in seconds since the Unix epoch. processes 556059------------------------------------------------Number of processes and threads created, include(but not limited to) those created by fork() or clone() system calls. procs_running 2-------------------------------------------------Current number of runnable threads procs_blocked 1-------------------------------------------------Current number of threads blocked, waiting for IO to complete. softirq 415893440 117 134668573 4001105 57050104 3510728 18 1313611 104047789 0 111301395---總softirq和各種類型softirq產生的中斷數：HI_SOFTIRQ,TIMER_SOFTIRQ,NET_TX_SOFTIRQ,NET_RX_SOFTIRQ,BLOCK_SOFTIRQ,IRQ_POLL_SOFTIRQ,TASKLET_SOFTIRQ,SCHED_SOFTIRQ,HRTIMER_SOFTIRQ,RCU_SOFTIRQ, /* Preferable RCU should always be the last softirq */
?
由cpu的各種時間可以推導出：
CPU時間=user+nice+system+idle+iowait+irq+softirq+steal+guest+guest_nice
CPU利用率=1-idle/(user+nice+system+idle+iowait+irq+softirq+steal+guest+guest_nice)
CPU用戶態利用率=(user+nice)/(user+nice+system+idle+iowait+irq+softirq+steal+guest+guest_nice)
CPU內核利用率=system/(user+nice+system+idle+iowait+irq+softirq+steal+guest+guest_nice)
IO利用率=iowait/(user+nice+system+idle+iowait+irq+softirq+steal+guest+guest_nice)
?
cat /proc/loadavg結果如下：
0.46 0.25 0.16 2/658 13300
?
1、5、15分鐘平均負載；
2/658：在采樣時刻，運行隊列任務數目和系統中活躍任務數目。
13300：最大pid值，包括線程。
?
2. 進程相關：/proc/xxx/stat
24021 (atop) S 1 24020 24020 0 -1 4194560 6179 53 0 0 164 196 0 0 0 -20 1 0 209898810 19374080 1630 18446744073709551615 1 1 0 0 0 0 0 0 27137 0 0 0 17 1 0 0 0 0 0 0 0 0 0 0 0 0 0
?
?
3. top
top是最常用來監控系統范圍內進程活動的工具，提供運行在系統上的與CPU關系最密切的進程列表，以及很多統計值。
第6章 進程啟動速度
進程啟動可以分為兩部分：
(1) 進程啟動，加載動態庫，直到main函數值錢。這是還沒有執行到程序員編寫的代碼，其性能優化有其特殊方法。
(2) main函數之后，直到對用戶的操作有所響應。涉及到自身編寫代碼的優化，在7、8章介紹。
6.1 查看進程的啟動過程
hello源碼如下：
#include <stdio.h>
#include <stdlib.h>int main()
{printf("Hello world!\n");return 0;
}
編譯：
gcc -o hello -O2 hello.c
strace用于查看系統運行過程中系統調用，同時得知進程在加載動態庫時的大概過程，-tt可以打印微妙級別時間戳。
strace -tt ./hello如下：
20:15:10.185596 execve("./hello", ["./hello"], [/* 82 vars */]) = 0
20:15:10.186087 brk(NULL) = 0x19ad000
20:15:10.186206 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
20:15:10.186358 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f24710ea000
20:15:10.186462 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
20:15:10.186572 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
20:15:10.186696 fstat(3, {st_mode=S_IFREG|0644, st_size=121947, ...}) = 0
20:15:10.186782 mmap(NULL, 121947, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f24710cc000
20:15:10.186857 close(3) = 0
20:15:10.186975 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
20:15:10.187074 open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
20:15:10.187153 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 832) = 832----------------libc.so.6文件句柄3，大小832。
20:15:10.187270 fstat(3, {st_mode=S_IFREG|0755, st_size=1868984, ...}) = 0
20:15:10.187358 mmap(NULL, 3971488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f2470afd000
20:15:10.187435 mprotect(0x7f2470cbd000, 2097152, PROT_NONE) = 0
20:15:10.187558 mmap(0x7f2470ebd000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c0000) = 0x7f2470ebd000---參數依次是：addr、length、prot、flags、fd、offset。
20:15:10.187662 mmap(0x7f2470ec3000, 14752, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2470ec3000
20:15:10.187749 close(3) = 0
20:15:10.187887 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f24710cb000
20:15:10.187992 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f24710ca000
20:15:10.188072 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f24710c9000
20:15:10.188191 arch_prctl(ARCH_SET_FS, 0x7f24710ca700) = 0--------------------------------set architecture-specific thread state, the parameters are code and addr。
20:15:10.188334 mprotect(0x7f2470ebd000, 16384, PROT_READ) = 0
20:15:10.188419 mprotect(0x600000, 4096, PROT_READ) = 0
20:15:10.188541 mprotect(0x7f24710ec000, 4096, PROT_READ) = 0
20:15:10.188633 munmap(0x7f24710cc000, 121947) = 0
20:15:10.188785 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
20:15:10.188965 brk(NULL) = 0x19ad000
20:15:10.189158 brk(0x19ce000) = 0x19ce000
20:15:10.189243 write(1, "Hello world!\n", 13Hello world!-----------------------------------往句柄1寫13個字符Hello world!\n。
) = 13
20:15:10.189299 exit_group(0) = ?
20:15:10.189387 +++ exited with 0 +++
?通過設置LD_DEBUG環境變量，可以打印出在進程加載過程中都做了那些事情：
LD_DEBUG=all ./hello如下。看似簡單的一個Hello world!，其系統已經做了很多準備工作。
13755: 13755: file=libc.so.6 [0]; needed by ./hello [0]----------(1) 搜索其所依賴的動態庫。13755: find library=libc.so.6 [0]; searching13755: search cache=/etc/ld.so.cache13755: trying file=/lib/x86_64-linux-gnu/libc.so.613755: 13755: file=libc.so.6 [0]; generating link map13755: dynamic: 0x00007fbac5cedba0 base: 0x00007fbac592a000 size: 0x00000000003c99a013755: entry: 0x00007fbac594a950 phdr: 0x00007fbac592a040 phnum: 1013755: 13755: checking for version `GLIBC_2.2.5' in file /lib/x86_64-linux-gnu/libc.so.6 [0] required by file ./hello [0]13755: checking for version `GLIBC_2.3' in file /lib64/ld-linux-x86-64.so.2 [0] required by file /lib/x86_64-linux-gnu/libc.so.6 [0]13755: checking for version `GLIBC_PRIVATE' in file /lib64/ld-linux-x86-64.so.2 [0] required by file /lib/x86_64-linux-gnu/libc.so.6 [0]13755: 13755: Initial object scopes------------------------------(2) 加載動態庫。13755: object=./hello [0]13755: scope 0: ./hello /lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.2 13755: object=linux-vdso.so.1 [0]
13755: scope 0: ./hello /lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.213755: scope 1: linux-vdso.so.113755: 13755: object=/lib/x86_64-linux-gnu/libc.so.6 [0]13755: scope 0: ./hello /lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.213755: 13755: object=/lib64/ld-linux-x86-64.so.2 [0]13755: no scope13755: 13755: 13755: relocation processing: /lib/x86_64-linux-gnu/libc.so.6 (lazy)13755: symbol=_res; lookup in file=./hello [0]13755: symbol=_res; lookup in file=/lib/x86_64-linux-gnu/libc.so.6 [0]13755: binding file /lib/x86_64-linux-gnu/libc.so.6 [0] to /lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol `_res' [GLIBC_2.2.5] ...13755: symbol=__vdso_time; lookup in file=linux-vdso.so.1 [0]13755: binding file linux-vdso.so.1 [0] to linux-vdso.so.1 [0]: normal symbol `__vdso_time' [LINUX_2.6]13755: symbol=__vdso_gettimeofday; lookup in file=linux-vdso.so.1 [0]13755: binding file linux-vdso.so.1 [0] to linux-vdso.so.1 [0]: normal symbol `__vdso_gettimeofday' [LINUX_2.6]13755: 13755: relocation processing: ./hello (lazy)13755: symbol=__gmon_start__; lookup in file=./hello [0]13755: symbol=__gmon_start__; lookup in file=/lib/x86_64-linux-gnu/libc.so.6 [0]13755: symbol=__gmon_start__; lookup in file=/lib64/ld-linux-x86-64.so.2 [0] ...13755: 13755: calling init: /lib/x86_64-linux-gnu/libc.so.6--------(3) 初始化動態庫。13755: 13755: symbol=__vdso_clock_gettime; lookup in file=linux-vdso.so.1 [0]13755: binding file linux-vdso.so.1 [0] to linux-vdso.so.1 [0]: normal symbol `__vdso_clock_gettime' [LINUX_2.6]13755: symbol=__vdso_getcpu; lookup in file=linux-vdso.so.1 [0]13755: binding file linux-vdso.so.1 [0] to linux-vdso.so.1 [0]: normal symbol `__vdso_getcpu' [LINUX_2.6]13755: symbol=__libc_start_main; lookup in file=./hello [0]13755: symbol=__libc_start_main; lookup in file=/lib/x86_64-linux-gnu/libc.so.6 [0]13755: binding file ./hello [0] to /lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol `__libc_start_main' [GLIBC_2.2.5]13755: 13755: initialize program: ./hello--------------------------(4) 初始化進程。13755: 13755: 13755: transferring control: ./hello------------------------(5) 將程序的控制權交給main函數。13755: 13755: symbol=puts; lookup in file=./hello [0]13755: symbol=puts; lookup in file=/lib/x86_64-linux-gnu/libc.so.6 [0]13755: binding file ./hello [0] to /lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol `puts' [GLIBC_2.2.5]13755: symbol=_dl_find_dso_for_object; lookup in file=./hello [0]13755: symbol=_dl_find_dso_for_object; lookup in file=/lib/x86_64-linux-gnu/libc.so.6 [0]13755: symbol=_dl_find_dso_for_object; lookup in file=/lib64/ld-linux-x86-64.so.2 [0]13755: binding file /lib/x86_64-linux-gnu/libc.so.6 [0] to /lib64/ld-linux-x86-64.so.2 [0]: normal symbol `_dl_find_dso_for_object' [GLIBC_PRIVATE] Hello world!-------------------------------------------------------(6) 執行用戶程序。13755: 13755: calling fini: ./hello [0]---------------------------(7) 執行去初始化動作。
?
6.2 減少加載動態庫的數量
正如《Systems Performance》所說的，最好的優化就是取出不必要的工作。
(1) 將一些無用的動態庫去掉。
(2) 重新組織動態庫的結構，力爭將進程加載動態庫的數量減到最小。
(3) 將一些動態庫編譯成靜態庫，與進程或其他動態庫合并。
優點是：
- 減少了加載動態庫的數量。
- 在與其他動態庫合并之后，動態庫內部之間的函數調用不必再進行符號查找、動態鏈接。
缺點是：
- 如果被其他進程或動態庫依賴，則會導致被復制多份，占用更多空間。
- 失去了代碼段內存共享，導致內存使用增加。
- 由于被多個進程使用，導致page fault增多，進而影響加載速度。
因此，對于只被很少進程加載的動態庫，將其編譯成靜態庫，減少進程啟動時加載動態庫的數量。對于那些守護使用的動態庫，代碼段大多已經被加載到內存，運行時產生的page fault要少，因此動態庫反而要比靜態庫速度更快。
(4) 使用dlopen動態加載動態庫。可以精確控制動態庫的生存周期，一方面可以減少動態庫數據段的內存使用，另一方面可以減少進程啟動時加載動態庫的時間。
6.3 共享庫的搜索路徑
在進程加載動態庫是，loader要從很多路徑搜索動態庫，搜索順序是：DT_NEED-->DT_RPATH-->LD_LIBRARY_PATH-->LD_RUNPATH-->ld.so.conf-->/lib /usr/lib。
DT_RPATH和LD_RUNPATH是程序編譯時加的選項，使用-rpath來設置DT_RPATH。
還存在一種比DT_RPATH更高優先級的目錄搜索機制HWCAP。HWCAP是為了支持系統根據不同的硬件特性，道不同的目錄去搜索動態庫。
可以通過屏蔽LD_HWCAP_MASK減少搜索路徑。
export LD_HWCAP_MASK=0X00000000
?
6.4 動態庫的高度
依據動態庫之間的依賴關系，從當前動態庫到最底層動態庫之間的最長路徑，成為該動態庫的高度。
降低動態庫的高度，有利于提高加載時間。
6.5 動態庫的初始化
在loader完成對動態庫的內存應設置后，需要運行動態庫的一些初始化函數，來完成設置動態庫的一些基本環境。包括兩部分：
(1) 動態庫的構造和析構函數機制
首先構造三個文件hello.c、hello.h、main.c。
===========hello.c============
#include <stdio.h>void __attribute__ ((constructor)) my_init(void)
{printf("constructor\n");;
}void __attribute__ ((destructor)) my_finit(void)
{printf("destructor\n");;
}void hello(const char *name)
{printf("Hello %s!\n", name);
}===========hello.h============
#ifndef HELLO_H#define HELLO_Hvoid hello(const char *name);#endif //HELLO_H
===========main.c============
#include "hello.h"int main(){hello("everyone");return 0;}
?
然后編譯庫(gcc -fPIC -shared -o libmyhello.so hello.c)、拷貝庫到系統lib目錄(sudo cp ?libmyhello.so /usr/lib)、編譯執行文件(gcc -o hello main.c -L./ -lmyhello)。
執行./hello結果如下：
constructor Hello everyone! destructor
?
(2) 動態庫的全局變量初始化工作
在C語言中，全局變量保存在.data段。再啟動過程中，loader只是簡單地使用mmap將數據段映射到dirty page，這些變量只有在第一次使用到的時候才會為其分配物理內存。
從優化的角度來講，要盡量減少全局對象的使用。
6.6 動態鏈接
?首先給一段代碼，基于此看看動態鏈接的過程。
#include <stdio.h>int main()
{printf("hello\n");return 0;
}
?
printf是glibc中定義，采用動態庫，在程序編譯階段，編譯器無法得知printf函數地址。
在程序運行時，當調用printf的時候，程序會將處理權交給linker，由其負責在執行文件以及其連接的動態庫中查找printf函數地址。
由于linker不知道printf具體在哪個動態庫，所以將在整個執行文件和動態庫范圍內查找。
26221: 26221: runtime linker statistics:26221: total startup time in dynamic loader: 703291 cycles26221: time needed for relocation: 188666 cycles (26.8%)26221: number of relocations: 7726221: number of relocations from cache: 326221: number of relative relocations: 119926221: time needed to load objects: 325593 cycles (46.2%) hello26221: 26221: runtime linker statistics:26221: final number of relocations: 8226221: final number of relocations from cache: 3
?
可以看出及時簡單打印hello，在啟動過程中查找、鏈接了很多符號，耗費了大量cpu cycle。
優化的方法：
(1) 減少導出符號的數量
通過去掉那些動態庫中不必導出的符號，從而減少動態庫在做鏈接時所查找的符號的數量，可以加快動態鏈接的速度。
(2) 減少符號的長度
在做符號鏈接時，linker將做字符串的匹配，符號名字越長，其查找匹配的時間越長。
(3) 使用prelink
如果動態庫在編譯的時候就能確定運行時的加載地址，那么動態庫函數調用的地址就應該是已知的，在進程運行的時候就沒有必要再進行符號的查找和鏈接，從而節省進程的啟動時間。
?
6.7 提高進程啟動速度
1. 將進程改為線程
2. prefork進程
3. preload進程
4. 提前加載，延后退出
5. 調整CPU的頻率
總體來講，優化進程的啟動速度的順序為：
(1) 優化動態庫的搜索路徑
(2) 檢查進程中是否有無用的動態庫
(3) 減少進程或所依賴動態庫的全局對象的數量
(4) 使用prelink，預先鏈接進程的動態庫
(5) 考慮重新組織動態庫，爭取減少進程加載動態庫的數量
(6) 考慮使用dlopen，將一起啟動時不需要的動態庫從進程的依賴動態庫中去除
如果仍然無法滿足要求，可以采用調度的方法：
(1) 進程改為線程
(2) preload進程
(3) 提前加載、延遲退出。
6.8 進程冷起與熱起的區別
在程序第一次啟動(冷起)退出后，再次啟動速度明顯比第一次快，為什么呢？
在程序第一次啟動、退出后，進程雖然被銷毀了，但是進程代碼段所占用的物理內存并沒有被銷毀；而是被Linux緩存起來，保存在Cache中。
這樣程序再次啟動時，指令不必再從Flash讀到內存中，而是直接使用Linux內核中的Cache，減少了程序啟動過程中所產生的page fault，從而加快了進程的啟動速度。
在進程啟動過程中：
(1) ?進程冷起時，如果運行的指令較多，則出現的page fault較多，影響進程的啟動速度。
(2) 進程所依賴的某些動態庫可能已經被一些守護進程所加載，其代碼段已經在內存中，故這種動態庫對進程的冷起和熱起性能影響不大。
(3) 沒有被其他進程使用過的動態庫，在冷起時則會產生page fault影響進程的啟動速度。
??
第7章 性能優化的方法
程序優化！=編碼技巧
編碼技巧是程序優化的一部分；程序優化涉及到硬件架構、程序架構、邏輯設計等，還有一點如何確定代碼瓶頸位置很重要。
7.1 尋找程序熱點
1. gprof
#include <stdio.h>void funca()
{int i = 0, n = 0;for(i=0; i<10000000; i++){n++;n--;}
}void funcb()
{int i = 0, n = 0;for(i=0; i<10000000; i++){n++;n--;}
}int main()
{int i=0;for(i=0;i<10;i++){funca();}funcb();return 0;
}
?
然后編譯(gcc performance.c -pg -o performance)、運行(./performance)、查看結果(gprof performance gmon.out -q -p)。
gprof performance gmon.out -pFlat profile:Each sample counts as 0.01 seconds.% cumulative self self total time seconds seconds calls ms/call ms/call name 91.95 0.40 0.40 10 40.46 40.46 funca9.20 0.45 0.04 1 40.46 40.46 funcb=========================================gprof performance gmon.out -qCall graph (explanation follows)granularity: each sample hit covers 2 byte(s) for 2.25% of 0.45 secondsindex % time self children called name<spontaneous> [1] 100.0 0.00 0.45 main [1]0.40 0.00 10/10 funca [2]0.04 0.00 1/1 funcb [3] -----------------------------------------------0.40 0.00 10/10 main [1] [2] 90.9 0.40 0.00 10 funca [2] -----------------------------------------------0.04 0.00 1/1 main [1] [3] 9.1 0.04 0.00 1 funcb [3] -----------------------------------------------
?
2. oprofile
7.2 程序邏輯瓶頸
oprofile只能有助于發現熱點，但是對程序熱點與代碼邏輯對應關系無法對應，因此不能定位由邏輯問題所造成的瓶頸。
可以通過添加日志的方法來確定不同邏輯部分耗時。進而找出邏輯問題。
PS：這里作者講到的日志多造成的副作用，在動態log，和可以添加filter的log中是不存在的。
7.3 優化的層次
1. 針對某一特定事例的優化，考慮使用oprofile，查找熱點，進行優化。主要以擴及優化為主、程序熱點函數優化為輔。
2. 系統整體性能的提高，分兩層：業務邏輯的優化和底層基礎函數性能優化。
上層業務邏輯優化：重點在于邏輯的調整、算法的優化。
底層基礎函數游湖：重點在于代碼的寫作技巧。
7.4 何時開始性能優化
?(1) 在需求階段，就要把性能指標定義下來。
?(2) 在軟件設計階段，要考慮這些性能指標，根據指標來考慮程序所使用的算法、邏輯，在這個階段考慮邏輯上的優化。
?(3) 在軟件功能基本完成后，一方面軟件的邏輯要做一些細微調整，另一方面要開始使用oprofile之類的工具查找熱點函數，對熱點函數做代碼優化。
7.5 如何推動系統性能優化
?(1) 需要找出一些關鍵的步驟，這些步驟性能直接影響著用戶使用體驗。
?(2) 為這些關鍵的過程定義相應的性能指標。
?(3) 在定義性能指標后，需要測試現系統，看看各個過程和目標性能之間的差距。
?(4) 拿到結果之后嗎，需要和相應開發團隊談判，要求其優化代碼。
?當優化任務 陷入僵局的時候，要求相應團隊出具兩份報告：一，從程序邏輯考慮，程序都做了哪些事情，每個事情花了多少時間，主要算法是什么；二，這個過程中oprofile報告，包括每個函數執行時間占比。查看前幾名函數邏輯上是否合理；對于前幾名函數，檢查其從算法實現到代碼優化層次是否能夠進行優化。
(5) 在各個團隊優化完代碼之后，返回流程(3)從新測試性能。如沒有達標，繼續3~5過程。
7.6 為什么軟件性能會低下
7.7 程序邏輯優化
?5個程序優化的思路：
(1) Do it faster：找到最有效率的方法，來提高程序的運行速度。
(2) Do it in parallel：并行加快執行速度。
(3) Do it later：不必要的功能，可以考慮延后執行，騰出資源做重要的事。
(4) Don't do it at all：最好的優化就是不做事。
(5) Do it before：把一些工作空閑時預先完成。
?
第8章 代碼優化的境界
?從高級語言C/C++，到指令在系統上運行，分兩個階段：
(1) 編譯器將C/C++轉變成可以在系統上運行的機器指令。編譯器會對代碼進行優化，優化后的機器指令可能與編寫的代碼有較大差異。
(2) 機器指令在不同硬件上執行，與體系結構、執行環境有密切關系。
所以優化代碼有兩個境界：從代碼看到編譯器優化后產生的匯編指令；根據芯片組特性，能看到匯編語言在硬件中執行狀態，比如流水線使用情況、緩存命中率等等。
?
8.1 GCC編譯優化
8.1.1 條件編譯
通過宏來降低條件判斷等操作，提高效率。
gcc -DXXX
8.1.2 指定CPU的型號
gcc -mcpu=XXX，是編譯出來的代碼能夠充分利用硬件平臺的特點，加快程序的執行速度。
8.1.3 builtin函數
GCC提供一些builtin函數來完成一些特殊功能。
(1) void *__builtin_apply_args(void);
(1) void *__builtin_apply(void (*func)(), void *arguments, int size);
(1) void *__builtin_return(void ?*result);
GCC網站http://gcc.gnu.org/onlinedocs/提供了builtin詳細信息。
8.1.4 GCC編譯優化
-O0 關閉編譯器優化
-O/-O1 增加了一些GCC優化代碼選項
-O2 除了完成所有-O1級別的優化之外，增加了比如處理器指令調度等。
-O3 除了完成所有-O2級別的優化之外，增加了循環展開和其他一些處理器特性相關優化工作。
8.2 優化基本原則
8.3 標準C代碼優化
8.4 C++代碼優化
8.5 硬件相關的優化
?
第9章 系統性能優化
9.1 Shell腳本優化
9.1.1 Shell腳本優化
在嵌入式Linux中，bash腳本占很大比重。優化shell有助于縮短系統啟動時間，加快進程的執行速度。
在Linux bash shell一般由Busybox實現，命令主要被分為兩大類：built-ins和applets。
Built-ins只是簡單的函數調用，而applets則意味著需要調用"fork/exec"創建子進程來執行，并且busybox也可以使用外部命令。
處于性能考慮，應使用built-ins來代替applets和外部命令。
輸入busybox，可以看到支持的所有功能。
include/applets.h中，定義了BusyBox支持的所有功能。
docs/nofork_noexec.txt中，說明了built-ins和applets的區別。
applets.h定義功能的時候，也定義了類型，分類如下：
(1) APPLET：即applets，創建一個子進程，然后調用exec執行相應的功能，執行完畢后，返還控制給父進程。
(2) APPLET_NOUSAGE：BusyBox中不包含該命令的幫助文檔。
(3) APPLET_NOEXEC：調用fork創建子進程，然后執行BusyBox對應功能，執行完畢后，返回控制給父進程。
(4) APPLET_NOFORK：相當于built-ins，只執行BusyBox內部函數，不創建子進程，效率最高。
9.1.2 bash腳本
包含在pipe中的built-ins將創建子進程來執行。
包含在'中的命令將創建子進程來執行。
對bash腳本進行優化時，要盡量避免fork進程。
9.1.3 如何優化busybox bansh腳本
(1) 去掉腳本中無用的代碼
(2) 盡可能使用busybox中的built-ins替換外部命令
printf "Starting" --> echo "Starting"
(3) 盡可能不使用pipe
(4) 減少pipe中的命令數
(5) 盡可能不適用"'"
更多方法參考：Optimize RC Scripts
9.2 使用preload預先加載進程
在系統比較空閑時，通過將特定程序的代碼從Flash加載到Cache，加快進程執行速度。
能否控制在Cache內存回收時，對某些關鍵進程所占用的Cache盡量少回收，加大某一進程Cache內存數量。
Linux有一個開源項目preload，就是利用控制Linux中的cache，來加快進程的啟動速度。
類似的技術有prelink和readahead
9.3 調整進程的優先級
?在Linux內核中，支持兩種進程：實時進程和普通進程。
(1) 實時進程
實時進程的優先級是靜態設定的，只有當運行隊列沒有實時進程的情況下，普通進程才能夠獲得調度。
實時進程采用兩種調度策略：SCHED_FIFO和SCHED_RR。
FIFO采用先進先出的策略，對于所有相同優先級的進程，最先進入runqueue的進程總能優先獲得調度；Round Robin采用更加公平的輪轉策略，使得相同優先級的實時進程能夠輪流獲得調度。
對于實時進程來講，使用絕對優先級概念，絕對優先級取值范圍是0~99，數字越大，優先級越高。
(2) 普通進程
Linux 2.6普通進程的絕對優先級取值是0，普通進程有靜態優先級和動態優先級之分。
可以通過nice修改進程的靜態優先級。
系統在運行過程中，在靜態優先級基礎上，不斷動態計算出每個進程的動態優先級，擁有最高優先級的進程被調度器選中。
動態優先級計算公式：動態優先級=max(100,min(靜態優先級-bonus+5，139))
bonus取決于進程的平均睡眠時間。
對實時進程設置通過如下函數進行：
#include <sched.h> int sched_setscheduler(pid_t pid, int policy, const struct sched_param *param); int sched_getscheduler(pid_t pid); int sched_setparam(pid_t pid, const struct sched_param *param); int sched_getparam(pid_t pid, const struct sched_param *param);
?
pid：指定所要設置的進程號，pid為0，表示為當前進程。
policy：設置進程調度策略，SCHED_OTHER/SCHED_FIFO/SCHED_RR。
param：設置進程的絕對優先級，范圍是0~99。
?
對普通進程來講，絕對優先級為0，通過nice來影響進程的調度。
nice取值-20~19，可以通過setpriority來設置普通進程優先級。
#include <sys/resource.h> int setpriority(int class, int id, int niceval);
?
class：PRIO_PROCESS/PRIO_PGRP/PRIO_USER。
niceval：為進程nice值，-20~19。
?
對實時線程操作，使用pthread_setschedparam；對普通線程，仍然可以使用setpriority和nice來調整線程優先級。
9.4 讓進程運行的慢一些
?對于某些沒有時限要求的進程，可以降低運行速度。
(1) 降低進程優先級。
(2) 增加一些代碼來控制Linux中進程的調度，如sched_yield自愿放棄CPU，進程仍然處于TASK_RUNNING狀態，但調度器把它放在運行隊列鏈表的末尾。
9.5 守護進程的數量
?守護進程占用大量動態庫代碼段和數據段內存，內存蟹柳概率加大，CPU性能下降，導致系統整體性能下降。
9.6 文件系統
?主要看基于Flash和RAM的兩大類文件系統。
基于Flash的文件系統：JFFS2、YAFFS2、Cramfs、Romfs，YAFFS2目前被廣泛運用。
基于RAM的文件系統：Ramdisk(在Linux啟動，initrd提供將內核映像和根文件系統一起載入內存)、Ramfs/tmpfs(把所有的文件都放在RAM中)。
9.7 使用Lmbench了解你的系統
?
9.8 系統的啟動
?關于Linux啟動速度，有一個網頁進行了詳細的總結：Boot Time。
9.9 系統耗電量
?本章節所講技術已經落后。
總結
以上是生活随笔為你收集整理的嵌入式linux内存使用和性能优化的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 海信VIDAA K1G小聚魔盒最新评价怎
- 下一篇： 牛群牛杂加盟费要多少钱