SteamDeck想必大家都玩上了吧，雖然它配置不強，但體驗着實非常不錯。它正在取代switch占用你的時間精力。
然而一些遊戲在它孱弱的小身闆上跑，依然存在不盡如人意的地方。比如莫名的卡頓，幀數過低。
本月CryoBate33大神為SteamDeck玩家帶來了一款優化神器GitHub - CryoByte33/steam-deck-utilities: A utility to improve performance and help manage storage on Steam Deck. 。
讓遊戲的0.1%的low幀平均幀提升了10-25%，high幀提升雖然不如low幀明顯，但也有大約5%的提升。0.1%low幀相比high幀更加重要，它反應了每千張畫面的卡頓次數，它直接表現的是遊戲的卡頓程度。
上圖是使用了CU2.0（67FPS），下圖是未使用（56FPS）
CU2.0的代碼是go語言編寫的。
其中，最核心的代碼位于紅框框起來的幾個檔案。耐心看會發現，作者通過調整諸如swap規模，gpu vram虛拟顯存大小，記憶體巨頁和巨頁壓縮系數等核心參數來改善系統對于高負載應用的性能和綜合表現。通過對比也不難發現這些參數對于特定遊戲确實提升巨大。
比如《古墓麗影》當把SWAP規模調整到16GB的時候，0.1%的Low幀提升居然高達76%，對于卡頓的改善幾乎是不用腦補的。
同時對比一下cu2.0相比cu1.0的綜合提升也是肉眼可見。
SteamOS的底層是Archlinux，是以一般ArchLinux上面的優化手段也是可以應用在SteamOS上的。ArchLinux預設的核心參數，可能并不是為了高負載前台應用而存在的，作者對他們進行微調，讓系統對前台應用傾斜更多資源，進而讓遊戲改善幀數，俗稱榨幹機能。那麼我們不妨來看看，作者都在哪些參數上面做了文章呢？
Swap Size （ArchWiki）
swap分區是用來改善記憶體壓力的，cu2.0把記憶體也劃了不少給GPU充當虛拟顯存，是以記憶體壓力還是挺大的，是以作者加大了swap size。是以各位小夥伴在改裝steamdeck的時候，一定要買優質高速的ssd呀。
Swappiness（ArchWiki）
swappiness決定了作業系統會不會激進的排程swap，這個值預設給的比較低，作業系統會盡量避免排程swap。但CU2.0因為挪用了一部分記憶體到顯存，加上也加大了swap size，是以這個政策也必須相應的調大才能獲得更好的性能，同時避免記憶體溢出。當然有得必有失，就像蘋果的macbook那樣激進的話，ssd的磨損也會加速。不過steamdeck的ssd畢竟是可拆卸的嘛，這點還是比蘋果厚道滴！
Transparent Hugepages
透明巨頁是rhel6引入的非人工手動維護的自動巨頁管理。預設是關閉的，CU2.0開啟了這個設定。
cpu在尋址記憶體的時候，通常是以page為機關擷取，而ArchLinux預設page size是4k。應用在擷取記憶體的時候是虛拟位址，這就是為什麼應用的記憶體位址總是從0開始，那麼系統就需要一個映射表，來對記憶體的真正位址進行映射。這些映射記錄本身也存在記憶體上。4GB 存儲空間就需要 4GB/4KB=1M 條記錄。周遊100萬條記錄的時間損耗對于性能要求高的場景是難以接受的。是以Linux2.6開始加入了『巨頁』概念，一個頁可能直接就1G，甚至16G。一次尋址搞定，顯著降低缺頁中斷。但是對于日常運用而言，巨頁是非常浪費記憶體的行為，可能導緻背景應用運作不穩定。算是以空間換時間。不過對于steamdeck而言，非常合适。
Compaction Proactiveness
壓縮積極性，這個設定跟java語言的垃圾回收差不多一個意思。這個參數決定了記憶體在被釋放之後，作業系統會不會立即回收。作者認為，盡管作業系統通常會計算一個合适的時間點去幹這件事情，但是對于steamdeck這種遊戲裝置來說，作業系統認為的合适時間，通常不是合适時間，是以直接把這個參數設定成0（又有蘋果那味兒了。咦，為什麼要說又呢？），别你丫的亂整理記憶體了，哪怕隻有200ms，畢竟這寶貴的200ms決定了我那關鍵一滾會不會被鮮血君王拍死。再說，我也沒有windows玩家強迫症，動不動手動清理記憶體，整理碎片找心理安慰。
還有許多參數，就不做一一說明了。有興趣的可以看看作者寫的文檔。他的調教方式雖然不是Linux最推薦的，但确實更适合遊戲機，很多排程政策也跟蘋果不謀而合。手上有steamdeck的各位，趕緊行動起來吧？