: 推 kira925 : 那一串后面Linus还多回了几段XD 08/11 10:31
大致翻一下好了
基本就是真·闲聊
source同个来源
一封是说Linus自己也是很注重单核效能的
毕竟Amdhal's Law摆在那边(*1)
但是单核效能水准zen 2也已经很不赖了，足敷他的需求
而他自己最常需要做、且吃重效能的工作是编译kernel
尽管还是会有不能平行化的部分
需要整个重编的情况刚好都是平行化得很好的，甚至能用上几百个核心
当然以这样的workflow来说他弄个TR甚至专用的farm会是个更高效的选择
但是这些偏伺服/hedt的零件建置起来麻烦
并且机器通常偏吵而占空间
不符他的个人喜好
一封是解释为什么还没看到因为rdrand出事而造成kernel出bug的回报
并且对这次事件下些评论
Linus认为zen 2的rdrand问题应该跟以前amd也曾经出现过的rdrand问题不太一样
而目前看来可以透过微码更正这个问题
代表这个问题的肇因实际上应该蛮蠢的
kernel多少有用到rdrand指令没错
不过设计上kernel并不是完全信赖这个指令
都会对产生的值进行其它处理
并且也没有重复call很多次(*2)
因此Linus认为AMD坏掉的rdrand应该不会对kernel造成什么可观测到的影响
不过还是自嘲这句话是个大大的flag
这次事件来说
kernel因为其设计上的细心所以没出啥漏子
但是上次那波rdrand还是影响到了openssl
而这次至少也有systemd受害
原则上来说我们不应该相信指令有问题的cpu上跑出来的结果
这次整体来说问题不大，只是令人对AMD感到失望
至少明显可以看出AMD的测资没有cover到rdrand这块
如果这是zen 2唯一的问题的话
对于AMD会是件再好不过的事
不过这架构太新了，因此显然我们目前的测资也不完善，还不能妄下定论。
按：
1. Amdahl's Law
假设一个task有27.648%不可能平行化
那么无论再怎么优良的设计
就算其他1-27.648%的task因为理想的平行化而需要的时间趋于0
还是需要单核去干掉剩下那部分
因此这个case无论核心数再怎么堆程式再怎么平行化
加速效果不超过4倍
2.
intel的rdrand无论是需要等待的clock
还是其最高的throughput
都比amd的要好上一两个数量级
而且intel的无论16b 32b 64b耗时相同
amd的耗时则随一次需要的大小线性增长