繼續SPECCPU測試記錄，本文主要在前兩篇文章基礎上進行操作系統層面的調優來提高最終的得分，歡迎各位提供意見。
五、OS調優過程
1、tmpfs
介紹tmpfs情況
首先由於時間問題，沒有進行完整的tmpfs測試，只是選擇比較有代表性的幾個bench同時包括int和fp，測試結果如下所示：
int測試tmpfs的四個bench結果
int | xfs | tmpfs |
401 | 1710 | 1690 |
458 | 2680 | 2670 |
400 | 2840 | 2840 |
403 | 2310 | 2390 |
fp 測試tmpfs的四個bench結果
bench | xfs | tmpfs |
447 | 4850 | 4860 |
459 | 1010 | 1010 |
470 | 2040 | 2040 |
453 | 4310 | 4240 |
465 | 2710 | 2710 |
由上兩個表可見，tmpfs有升高有降低，因此爲了進一步驗證tmpfs對於整體的影響，所以整組bench一起測試完來驗證tmpfs下測試情況概述。
int的代號 | bench名稱 | xfs | tmpfs |
400 | perbench | 2840 | 2850 |
401 | bzip2 | 1710 | 1700 |
403 | gcc | 2310 | 2380 |
429 | mcf | 4010 | 3840 |
445 | gobmk | 2570 | 2590 |
456 | hmmer | 4980 | 4970 |
458 | sjeng | 2680 | 2670 |
462 | libquantum | 37900 | 37900 |
464 | h264ref | 4670 | 4790 |
471 | omnetpp | 1420 | 1430 |
473 | astar | 1880 | 1880 |
483 | xalancbmk | 3390 | 3410 |
結果 |
| 3410 | 3420 |
爲了讓顯示更加可比較，因此將462的結果37900設置成3790。如圖和表中所示，tmpfs下有6個結果上升了，2個結果保持一致，有4個稍微降低了，最終結果有所提升。
結論：針對int結果顯示，tmpfs對於結果有所提升。
2、sysctl（sched_latency_ns、max）
經過分析，系統的內核參數可能對於最終結果有所影響，因此首先通過對比redhat和Neokylin操作系統默認的內核參數的區別。因此找到不同的幾項參數
1)kernel.sched_latency_ns
內核調度延遲時間，默認爲24000000ns，修改爲12000000ns，並進行測試。
修改方法:#sysctl kernel.sched_latency_ns=12000000即可。
由於時間有限，選擇一個bench403進行比較。
| 默認 | latency_ns=12000000 |
403 | 2310 | 2310 |
上述結果爲設置與否沒有影響，但是不能下結論說這個參數一定沒有影響，等待後續時間充裕的情況下，測試整組bench來完整的驗證此參數的影響；
2）MALLOC_AREAN_MAX
該環境變量影響內存分配問題，新版本glibc（2.11）爲了提升內存分配性能，每個線程分配了內存池，64位操作系統默認是64M，可以通過這個變量進行修改。
通過export MALLOC_ARENA_MAX值來進行測試，測試結果如下所示：
MALLOC_ARENA_MAX | 未設置 | 未設置 | 2 | 4 |
filesystem | xfs | tmpfs | tmpfs | xfs |
401 | 1710 | 1690 | 1700 | 1690 |
458 | 2680 | 2670 | 2670 | 2670 |
400 | 2840 | 2840 | 2830 | 2840 |
403 | 2310 | 2390 | 2380 | 2310 |
上述結果中可見，當將參數設置爲2時，此時和相同文件系統tmpfs相比，2個下降，1個未變一個升高。由此可見，對於將MALLOC_ARENA_MAX設置爲2時，有可能提高最終結果，需要在時間允許的情況下進行完整的bench測試。xfs文件系統情況下，將MALLOC_ARENA_MAX設置爲4時，結果2個下降2個不變，基本可以判定xfs下修改此參數爲4結果不好，以後設置時可以放棄。
如上表所示，只是設置了2和4兩個值，還有多個值沒有嘗試。因此，在時間允許的情況下，可以進行更多的測試來驗證此值是否有影響。
結論：tmpfs下將MALLOC_ARENA_MAX修改爲4可能提高最終結果，未來時間可以進行完整性測試。
3、更換三星內存
經過多次測試以及Intel給的建議，本次實驗中進行三星內存的測試，最終發現針對這款主板下，海力士的內存更加合適。
原本內存：64*16G，海力士內存2Rank，容量1TB，頻率
更改內存：64*32G，三星內存2Rank，容量2TB，頻率
結果顯示10個下降，1個不變，1個上升，最終結果降低20分，3390。由此可見，三星內存的效果沒有原來海力士16GB結果好。同時爲了進一步驗證此內存的問題，我們利用stream工具來測試內存的吞吐量。海力士測試的吞吐量爲258GB/s，而三星的內存吞吐率下降了4GB/s，在254GB/s左右。
結論：目前來看三星內存針對當前的主板，其效果不如海力士的好。由此測試發現，針對SPECCPU來說，CPU佔據最主要地位，而內存影響較小。同時，針對內存插法、BIOS中memory interleave設置等相關設置均有待繼續研究。同一個channel，三個插槽情況下，插入的內存條數越多則會降頻。因此，大部分人選擇將三個插槽中插入兩個，以達到容量和頻率的平衡。
4、嘗試tuned-profile，latency-performance、throughput-performance
系統自帶的tuned模式有多種，現在系統自帶的有如下模式：
#tuned-adm list
Available profiles:
- balanced
- desktop
- latency-performance
- network-latency
- network-throughput
- powersave
- throughput-performance
- virtual-guest
- virtual-host
Current active profile:throughput-performance
經過分析其中latency-performance也是對於低延時高效率的計算而用的模式，因此修改模式爲latency-performance模式進行測試。修改辦法：
#tuned-adm profile latency-performance
再利用tuned-adm active查看是否設置成功。設置完成後利用一個bench進行測試，測試結果：
5、動態無時鐘
默認情況下，紅帽企業版 Linux 7 使用無時鐘內核，它不會中斷空閒 CPU 來減少用電量，並允許較新的處理器利用深睡眠狀態。
紅帽企業版 Linux 7 同樣提供一種動態的無時鐘設置（默認禁用），這對於延遲敏感型的工作負載來說是很有幫助的，例如高性能計算或實時計算。要啓用特定內核中的動態無時鐘性能，在內核命令行中用 nohz_full 參數進行設定。在 16 核的系統中，設定 nohz_full=1-15 可以在 1 到 15 內核中啓用動態無時鐘內核性能，並將所有的計時移動至唯一未設定的內核中（0 內核）。這種性能可以在啓動時暫時啓用，也可以在 /etc/default/grub 文件中永久啓用。要持續此性能，請運行 grub2-mkconfig -o /boot/grub2/grub.cfg 指令來保存配置。
啓用動態無時鐘性能需要一些手動管理。
當系統啓動時，必須手動將 rcu 線程移動至對延遲不敏感的內核，這種情況下爲 0 內核。
# for i in `pgrep rcu` ; do taskset -pc 0$i ; done
• 在內核命令行上使用 isolcpus 參數來將特定的內核與用戶空間任務隔離開。
• 可以選擇性地爲輔助性內核設置內核回寫式 bdi-flush 線程的 CPU 關聯：
echo 1 > /sys/bus/workqueue/devices/writeback/cpumask
驗證動態無時鐘配置是否正常運行，執行以下命令，其中 stress 是在 CPU 中運行 1 秒的程序。
# perf stat -C 1 -eirq_vectors:local_timer_entry taskset -c 1 stress -t 1 -c 1
可替代 stress 的是一個腳本，該腳本的運行類似 while :; do d=1; done 。以下鏈接中的程序是另一個合適的替代程序： https://dl.fedoraproject.org/pub/epel/6/x86_64/repoview/stress.html。
默認的內核計時器配置在繁忙 CPU 中顯示 1000 次滴答記號：
# perf stat -C 1-e irq_vectors:local_timer_entry taskset -c 1 stress -t 1 -c 1
1000 irq_vectors:local_timer_entry
動態無時鐘內核配置下，用戶只會看到一次滴答記號：
# perf stat -C 1 -e irq_vectors:local_timer_entrytaskset -c 1 stress-t 1 -c 1
1irq_vectors:local_timer_entry
雖然提到它可以提高高性能計算，但是由於在實際運行腳本中我們已經設定了numa綁定策略，這個與設置動態無時鐘的numa策略有衝突。因此，最終不能完成測試。
結論：滴答消耗只給CPU0，其他的CPU不進行時鐘滴答操作。理論上會有所提高，但是我們測試時rate的數量和內核數量一致，而此時利用taskset將時鐘滴答集中在CPU0上，所以數量肯定不夠，導致最終不能運行。如果測試中沒有使用到所有的core綁定，那麼則可以使用此性能來提高性能。
6、cpuscaling模式governor:performance、powersave
這個爲CPU擴展的模式，默認系統應該會選擇性能優化：performance。利用cpupower工具來查看當前的governor
#cpupower -c all frequency-info
部分結果如下所示
current policy: frequency should be within 800MHz and 3.20 GHz.
The governor "performance"may decide which speed to use
within this range.
在正式測試之前需要檢查這個模式是否爲performance，如果不是則需要利用
#cpupower -c all set-frequency -gperformance
來設置
7、irqbalance
9、默認numad服務開啓與否以及利用numad 命令
10、numa綁定策略
11、I/O策略以及參數(nr_requests、read_ahead_kb)[speccpu.txt]