timewarp

这年头干什么都得备案，防民如防贼

这不是好事，往陶哲轩方向培养，虽然陶不是阿斯伯格

https://systemsresearch.io 就是干

跟携程问道比如何

相亲软件的女生明摆着是来白嫖一顿饭的，吃完了还专门发微信谢谢你，玛德，简直欺负人，艹

我的 nvim 的配置全是 ai 帮我写的，想要什么跟他说就行

@diproxy

我们确实在 bios 里关了 numa ，384 个 cpu 只剩 192 了，内核 1.5T 也折半了。本来预期是超多核心会导致一些性能问题，可以比较好的体现我们组的价值，但是后来上面拍板把 numa 关了。至于 sub-numa ，这个我们还跟美团开会交流，讨论后结果也是承担不起性能的风险。

总的来说，现在内部的各种上线限制、操作规范一直在加强，稳定性的重要度一直在上升，惩罚措施当然也不断加重，新技术就成了新风险的代名词。

关于机器超多核导致的各种资源竞争我之前也观察到一些，尤其是有的容器一次性释放几十个 G 内存会瞬间把 sys 打满，每个 cpu 核心的 pcp_page_set 接收不住这么多内存，最后承压的还是伙伴系统。我曾经也想过实现一个无锁伙伴系统，还为此读了一些论文，目前确实没有很完美的工业界实现，我之前有个脑洞是把整个内存直接看做一颗满二叉树，然后借助 CAS 操作看看能不能搞一把。

多多技术还是强啊，要是多开几个分公司就好了

@diproxy

> 但我觉得最重要的一点是，公司高层对待新技术的开放性，没有这一点，其他上面我写了那么多文字都是扯淡。拼多多在这方面远好于贵司。高层的态度决定了公司的风格。

扎心了老铁。

第二点确实很关键，我司的业务都是能跑就行，指望他们对 iouring 这种提出需求那基本不可能了...
第三点，我司目前也是能用就行，bpf 这玩意儿有多少能力就用多少能力，不支持的功能就不用了...
第四点那在我司是彻底不可能了，引入高配 amd 机器还得因为 numa 性能问题改为单路了，解决不了性能问题就解决掉 numa...

至于 eevdf 这个词语在我司就是洪水猛兽了，当初调研升级系统时本来是把 openeuler22 和 openeuler24 都作为备选的，但是 openeuler24 用的是 6.6 内核，引入了 eevdf ，尽管这个内核有很多很棒的其他特性，但是仍然被否决了。

稳定性优先其实就是能不动就不动，不做就不会错。全公司自上而下其实没看到对技术有什么追求，可能自从当年章文嵩走了之后整个技术氛围就老化了。

@diproxy
其实我有个疑问，单纯的推进新内核似乎并不能完全产生收益，甚至可能背锅，我感觉“拿收益”一直是底层团队比较困扰的事情，不好讲清楚价值所在。

类似阿里这种公有云，场景很复杂，可以产生明确的内核需求，但是一般私有云基本停留在能跑就行的程度，想诞生一个需求实在是太难了。业务同事不懂内核，他们自己也不知道需要什么特性，而从内核这边把新特性反向推向业务去拿收益也比较难。