SteamDeck优化神器CryoUtilities2。0

　　SteamDeck想必大家都玩上了吧，虽然它配置不强，但体验着实非常不错。它正在取代switch占用你的时间精力。
　　然而一些游戏在它孱弱的小身板上跑，依然存在不尽如人意的地方。比如莫名的卡顿，帧数过低。
　　本月CryoBate33大神为SteamDeck玩家带来了一款优化神器GitHubCryoByte33steamdeckutilities：AutilitytoimproveperformanceandhelpmanagestorageonSteamDeck。。
　　让游戏的0。1的low帧平均帧提升了1025，high帧提升虽然不如low帧明显，但也有大约5的提升。0。1low帧相比high帧更加重要，它反应了每千张画面的卡顿次数，它直接表现的是游戏的卡顿程度。
　　上图是使用了CU2。0（67FPS），下图是未使用（56FPS）
　　CU2。0的代码是go语言编写的。
　　其中，最核心的代码位于红框框起来的几个文件。耐心看会发现，作者通过调整诸如swap规模，gpuvram虚拟显存大小，内存巨页和巨页压缩系数等内核参数来改善系统对于高负载应用的性能和综合表现。通过对比也不难发现这些参数对于特定游戏确实提升巨大。
　　比如《古墓丽影》当把SWAP规模调整到16GB的时候，0。1的Low帧提升居然高达76，对于卡顿的改善几乎是不用脑补的。
　　同时对比一下cu2。0相比cu1。0的综合提升也是肉眼可见。
　　SteamOS的底层是Archlinux，所以一般ArchLinux上面的优化手段也是可以应用在SteamOS上的。ArchLinux默认的内核参数，可能并不是为了高负载前台应用而存在的，作者对他们进行微调，让系统对前台应用倾斜更多资源，从而让游戏改善帧数，俗称榨干机能。那么我们不妨来看看，作者都在哪些参数上面做了文章呢？
　　SwapSize（ArchWiki）
　　swap分区是用来改善内存压力的，cu2。0把内存也划了不少给GPU充当虚拟显存，所以内存压力还是挺大的，所以作者加大了swapsize。所以各位小伙伴在改装steamdeck的时候，一定要买优质高速的ssd呀。
　　Swappiness（ArchWiki）
　　swappiness决定了操作系统会不会激进的调度swap，这个值默认给的比较低，操作系统会尽量避免调度swap。但CU2。0因为挪用了一部分内存到显存，加上也加大了swapsize，所以这个策略也必须相应的调大才能获得更好的性能，同时避免内存溢出。当然有得必有失，就像苹果的macbook那样激进的话，ssd的磨损也会加速。不过steamdeck的ssd毕竟是可拆卸的嘛，这点还是比苹果厚道滴！
　　TransparentHugepages
　　透明巨页是rhel6引入的非人工手动维护的自动巨页管理。默认是关闭的，CU2。0开启了这个设置。
　　cpu在寻址内存的时候，通常是以page为单位获取，而ArchLinux默认pagesize是4k。应用在获取内存的时候是虚拟地址，这就是为什么应用的内存地址总是从0开始，那么系统就需要一个映射表，来对内存的真正地址进行映射。这些映射记录本身也存在内存上。4GB存储空间就需要4GB4KB1M条记录。遍历100万条记录的时间损耗对于性能要求高的场景是难以接受的。所以Linux2。6开始加入了巨页概念，一个页可能直接就1G，甚至16G。一次寻址搞定，显著降低缺页中断。但是对于日常运用而言，巨页是非常浪费内存的行为，可能导致后台应用运行不稳定。算是以空间换时间。不过对于steamdeck而言，非常合适。
　　CompactionProactiveness
　　压缩积极性，这个设置跟java语言的垃圾回收差不多一个意思。这个参数决定了内存在被释放之后，操作系统会不会立即回收。作者认为，尽管操作系统通常会计算一个合适的时间点去干这件事情，但是对于steamdeck这种游戏设备来说，操作系统认为的合适时间，通常不是合适时间，所以直接把这个参数设置成0（又有苹果那味儿了。咦，为什么要说又呢？），别你丫的乱整理内存了，哪怕只有200ms，毕竟这宝贵的200ms决定了我那关键一滚会不会被鲜血君王拍死。再说，我也没有windows玩家强迫症，动不动手动清理内存，整理碎片找心理安慰。
　　还有许多参数，就不做一一说明了。有兴趣的可以看看作者写的文档。他的调教方式虽然不是Linux最推荐的，但确实更适合游戏机，很多调度策略也跟苹果不谋而合。手上有steamdeck的各位，赶紧行动起来吧？