我记得最近一年读过一篇排查线上故障的中文文章，大概是生产环境突然 cpu 爆炸（非物理），连 ssh 登录都要卡住，最后艰难排查发现是因为新部署的应用 elf .text 段巨大（> 10G?）吃满了内存，然后内核开始 page out .text 段，然而应用程序又要读 .text，所以又 page fault 进内存，节点上有好多个这样的应用和内核玩 page out - page fault 死循环玩爆了 cpu。
然后我翻了半天 ibug 和 qc 的频道没有找到，o3 帮我搜了半天也无结果😀我在孤独的路上没有尽头。如果哪位老师能顺手找到，我愿意为你😇
不过在翻 qc 频道的时候发现自己错过了这个： https://github.com/Evian-Zhang/static-keys
这个想法我也私下谈过几次了，动机来源是 bpf 本身由于多了一次用户态 load / CO-RE，这一步可以操作字节码可以把多余的分支全部剪掉；但是 native compiled elf 就要忍受半个 cycle 的浪费，能不能想办法也剪掉呢？static keys!
（甚至给了我一点更多启发，我知道怎么优化 bpf switch case 的 O(n) 了😇）
然后我翻了半天 ibug 和 qc 的频道没有找到，o3 帮我搜了半天也无结果😀我在孤独的路上没有尽头。如果哪位老师能顺手找到，我愿意为你😇
不过在翻 qc 频道的时候发现自己错过了这个： https://github.com/Evian-Zhang/static-keys
这个想法我也私下谈过几次了，动机来源是 bpf 本身由于多了一次用户态 load / CO-RE，这一步可以操作字节码可以把多余的分支全部剪掉；但是 native compiled elf 就要忍受半个 cycle 的浪费，能不能想办法也剪掉呢？static keys!
（甚至给了我一点更多启发，我知道怎么优化 bpf switch case 的 O(n) 了😇）