1. cyclictest 簡介以及安裝 1.1 cyclictest 簡介 cyclictest 是什麼? 看名字應該就能大致猜出來它是一種 test 程式,Cyclictest的維基主頁這麼介紹它“Cyclictest is a high resolution test program, wri ...
1. cyclictest 簡介以及安裝
1.1 cyclictest 簡介
cyclictest 是什麼? 看名字應該就能大致猜出來它是一種 test 程式,Cyclictest的維基主頁這麼介紹它“Cyclictest is a high resolution test program, written by User:Tglx, maintained by User:Clark Williams ”,也就是它是一個高精度的測試程式,Cyclictest 是 rt-tests 下的一個測試工具,也是rt-tests 下使用最廣泛的測試工具,一般主要用來測試使用內核的延遲,從而判斷內核的實時性。
1.2 cyclictest 安裝
1.2.1 基於包管理軟體安裝
Debian / Ubuntu 系統下可以直接使用apt-get install rt-tests 來安裝cyclictest。
1.2.2 git 倉庫源碼安裝
使用Linux最大的好處就是我們可以下載軟體的源碼,學習、編譯以及使用,所以如果使用上述方法直接安裝使用,如果你覺得有的問題不懂或者出現問題你也沒辦法解決,所以從開發者的角度而言,下載安裝軟體還是下載源碼包編譯後使用比較好。
(1) 首先拷貝cyclictest的Git 倉庫
# git clone git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git
(2) 進入git倉庫
# cd rt-tests
(3)創建一個分支,比如我們起名叫testing
# git branch testing
(4)轉到testing分支,之後我們做的步驟都不會對主分支有影響,這是我們在電腦上使用 git 倉庫的常用方法
# git checkout testing
(5)查看我們當前在哪個分支
# git branch
master
* testing
(6)在次我們使用make編譯
# make
編譯時我們會遇到缺失numa.h 的錯誤提示,在此我建議童鞋們安裝使用apt-file 來解決此類錯誤(有了apt-file,遇到這類錯誤我們就知道如何解決而不是一味的上網找別人的解決方法),主要步驟如下:
# sudo apt-get install apt-file // 安裝apt-file
# apt-file update // 類似於apt-get ,apt-file也需要根據系統配的源來更新一個庫
# apt-file search numa.h // 使用apt-file search 搜索我們缺失的文件
libhwloc-dev: /usr/include/hwloc/linux-libnuma.h
libnuma-dev: /usr/include/numa.h // 在搜索到的結果中,我們發現這個包叫做 libnuma-dev 應該就是我們需要安裝的包
linux-headers-3.2.0-4-amd64: /usr/src/linux-headers-3.2.0-4-amd64/include/config/acpi/numa.h
linux-headers-3.2.0-4-amd64: /usr/src/linux-headers-3.2.0-4-amd64/include/config/amd/numa.h
....
# apt-get install libnuma-dev // 使用apt-get 安裝libnuma-dev 包
2. cyclictest 的使用及參數簡介
對於Cyclictest的使用我們得先瞭解它的各個參數的含義,所以在你開始使用之前,請你看一下 cyclictest --help 中提到的各個參數!這將對你使用有很大的幫助。
2.1 cyclictest的簡單使用及結果分析
如果你只是想玩玩這個工具,那麼對於維基主頁上提到的tglx 使用的測試命令來測測你的電腦性能:
# sudo ./cyclictest -t1 -p 80 -n -i 10000 -l 10000
註:在rt-tests的路徑下,我們可以使用 ./cyclictest 來運行cyclictest, 而在別的目錄下,我們就需要指定 cyclictest的路徑來使用,比如說 /home/long/rt-tests/cyclictest ,或者你也可以直接將 rt-tests的路徑下的 cyclictest 拷貝到 /bin/ 下,以後就可以直接使用 cyclictest 而不需要指定路徑了!!
比如在我的電腦上,我使用這個命令測試的結果如下:
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.38 0.29 0.26 1/381 5595
T: 0 ( 5592) P:80 I:10000 C: 10000 Min: 2 Act: 15 Avg: 15 Max: 195
輸出結果含義:
T: 0 序號為0的線程
P: 0 線程優先順序為0
C: 9397 計數器。線程的時間間隔每達到一次,計數器加1
I: 1000 時間間隔為1000微秒(us)
Min: 最小延時(us)
Act: 最近一次的延時(us)
Avg:平均延時(us)
Max: 最大延時(us)
所以我們當前的機器上最小延時為2,平均為15,最大的為 195。
$uname -a // 我們可以使用 “ uname -a ” 看到我們系統目前使用的內核版本
Linux wheezy 3.2.51-trace #8 SMP Thu Nov 21 12:34:04 CST 2013 x86_64 GNU/Linux
$ cat /boot/config-3.2.51-trace |grep CONFIG_PREEMPT_RT // 我們再打開 /boot 下麵的當前內核的config信息查看目前這個內核是否打上實時補丁,結果顯示並沒有。所以在一個普通的內核下測的 Min: 2 Act: 15 Avg: 15 Max: 195 這樣的數據算是不錯的了!
$ cat /boot/config-3.10.17-trace-rt12 |grep CONFIG_PREEMPT_RT // 而在我 /boot 目錄下的另外一個打好實時補丁的內核中
CONFIG_PREEMPT_RT_BASE=y
# CONFIG_PREEMPT_RTB is not set
CONFIG_PREEMPT_RT_FULL=y // 判斷一個內核是否是實時內核,請看config 下有沒有此項
我得到的cyclictest 運行結果是這樣的:
T: 0 ( 5592) P:80 I:10000 C: 10000 Min: 1 Act: 1 Avg: 2 Max: 9
:-),運行的結果有目共睹,在以後的博客中我會介紹關於Linux 內核的實時補丁。
2.2 cyclictest 的參數介紹
關於cyclictest 的各個參數具體含義建議大家還是用時間具體看看 cyclictest --help 的信息(參考資料【2】為我的師兄對--help下的每個參數的解釋,大家也可以看看!)我這隻介紹幾個常用的。 -p PRIO --prio=PRIO 最高優先順序線程的優先順序 使用時方法為: -p 90 / --prio=90-m --mlockall 鎖定當前和將來的記憶體分配
-c CLOCK --clock=CLOCK 選擇時鐘 cyclictest -c 1
0 = CLOCK_MONOTONIC (預設)
1 = CLOCK_REALTIME
-i INTV --interval=INTV 基本線程間隔,預設為1000(單位為us),下麵介紹原理的時候會提到
-l LOOPS --loops=LOOPS 迴圈的個數,預設為0(無窮個),與 -i 間隔數結合可大致算出整個測試的時間,比如 -i 1000 -l 1000000 ,總的迴圈時間為1000*1000000=1000000000 us =1000s ,所以大致為16分鐘多。
-n --nanosleep 使用 clock_nanosleep
-h HISTNUM --histogram=US 在執行完後在標準輸出設備上畫出延遲的直方圖(很多線程有相同的許可權)US為最大的跟蹤時間限制,這個在下麵介紹實例時可以用到,結合gnuplot 可以畫出我們測試的結果圖。
-q --quiet 使用-q 參數運行時不列印信息,只在退出時列印概要內容,結合-h HISTNUM參數會在退出時列印HISTNUM 行統計信息以及一個總的概要信息。
-f --ftrace ftrace函數跟蹤(通常與-b 配套使用,其實通常使用 -b 即可,不使用 -f )
-b USEC --breaktrace=USEC 當延時大於USEC指定的值時,發送停止跟蹤。USEC,單位為謬秒(us)。
2.3 推薦參數以及結果實例
dslab@wheezy:~$ sudo cyclictest -p 90 - m -c 0 -i 200 -n -h 100 -q -l 1000000 我們使用 -p 90給cyclictest 賦優先順序90,使用-m參數鎖定記憶體分配,使用 -c 0指定使用預設的MONOTONIC 時鐘, -i 200 指定一個迴圈為200us,結合 -l 1000000為總共1000000個迴圈,此外-n 為使用nanosleep 而不是簡單的sleep,-q為在運行時不列印即時信息,-h 100 為總共統計100個信息在最後的結果中。# /dev/cpu_dma_latency set to 0us ---------------------------------------------------(下麵都是結束測試/終端測試後列印的信息,這就是 -q 的功效!)
# Histogram
000000 000000
000001 111448 -- 延時為1us的在1000000次迴圈中占111448次(下麵每行都是這個意思)
000002 060272
000003 000714
000004 000344
000005 000231
000006 013170
000007 155289
000008 601393
000009 044880
000010 005348
000011 001821
000012 001444
000013 000945
000014 000538
000015 000376
000016 000344
..... 000096 000002
000097 000002
000098 000002
000099 000002 -- 我們使用 -h 100 ,所以在結果中記錄了延時為 0us ~ 99us 的次數
# Total: 000999888
# Min Latencies: 00001 -- 最小延時 1 us
# Avg Latencies: 00006 -- 平均延時 6us
# Max Latencies: 00463 -- 最大延時463 us,那麼我們指定histogram = 100也就是只記錄了0us~99us的值而最大延時為463 也就是說肯定有很多此延時超過99 us,那麼記錄到哪了?答案是,沒有記錄具體的超過99us的延時值,只在下麵記錄了超過99us 的延時次數(記錄在Overflows),以及第幾次超過了(記錄在Thread 0)。
# Histogram Overflows: 00112 -- 超過99 us的次數
# Histogram Overflow at cycle number:
# Thread 0: 02985 06044 06107 08644 08683 12048 18136 30164 33172 33757 36214 48208 54138 58822 61284 83843 83876 86382 92351 92352 96306 108937 108941 111443 117367 129130 129131 146426 155069 155070 159058 161563 171486 184200 186614 209260 211606 221606 223526 223527 234275 234321 236827 241705 241706 246766 266826 296886 321946 334644 336979 337006 359705 367066 384765 392126 412186 437221 442246 462306 472306 484921 487366 497366 507426 509981 512448 512488 522426 542486 567546 587606 610305 617666 635365 637704 637726 660425 672686 692846 710379 710463 717806 735443 737919 742886 760582 763088 767946 785515 785642 788149 793086 806776 808146 810703 813146 835661 835847 838172 # 00012 others //這裡記錄的是第幾次迴圈的延時超過了99us。