早知如此，何必当初？
来自长期内核贡献者 James Bottomley 对本次事件的回复
https://lore.kernel.org/all/e7d548a7fc835f9f3c9cb2e5ed97dfdfa164813f.camel@HansenPartnership.com/
来自长期内核贡献者 James Bottomley 对本次事件的回复
https://lore.kernel.org/all/e7d548a7fc835f9f3c9cb2e5ed97dfdfa164813f.camel@HansenPartnership.com/
艺术，艺术啊
"根据相关法律法规, 该 maintainer 暂不予以展示"
过去一天无疑是耻辱和令人绝望的。我们目睹了 Linus Torvalds 对我社贡献者乃至工作的攻击、侮辱和诋毁。
上周日，一条践踏社区信任的、可耻的提交被无声合并。数十名俄罗斯藉 Linux 内核贡献者、子系统维护者在未被告知的情况下被革除维护者身份。 ¹ 在诸多提出质疑的内核贡献者与关注者中，我社人员也提出了自己的质疑和严厉批评。² ³ 而 Linux 基金会在此事中不仅没有发布任何公告解释行为，Linux 内核项目创始人和核心维护人员 Linus Torvalds 与 linux-stable 分支维护者 Greg Kroah-Hartman 两位技术人员更是伙同 Linux 基金会一道，开始了极具歧视性的“猎巫行动”。
在此次新一轮回应之前，昨日我社人员编撰的新闻稿中已有详细的背景介绍，此处全文贴出：
日前，Linux 内核主要维护者之一 Greg Kroah-Hartman (Greg K-H) 提交了一项不寻常的“文档”更新，将数名具有 <.ru> 顶级域名邮箱的维护者，和一名明确为俄罗斯身份的维护者从 MAINTAINERS（维护者名录）文件除名。
这一提交已于上周日被 Linus Torvalds 拉取并包含于 6.12-rc4 版本的代码中。
Greg K-H 并未详述这项更新的具体原因，仅含糊其辞地表示该更改是“由于某些合规性要求”，并指出“（相关人员）提供充足文档后，方可回归（维护者名录）”。
相关的维护者移除方式相当暴力，其中部分子系统由于唯一维护者使用 <.ru> 顶级域名邮箱，整个子系统都被从 MAINTAINERS 文件中移除，这之中不乏诸如 UFS 文件系统和 PPTP 驱动等重要且被广泛使用的子系统。由于 Linux 内核开发流程完全基于邮件列表进行，当 MAINTAINERS 文件中移除相关维护者后，也就意味着与相关子系统的补丁或沟通将不再被发送至维护者的邮箱，乃至相关的邮件列表。这很可能会造成许多补丁“石沉大海”；而如果某个子系统未得到充分维护，那么其被从内核中移除也只是时间问题了。
通常而言，Linux 内核补丁除了发送至邮件列表外，还需要抄送与之相关的人士（如子系统维护者和活跃贡献者），并且经过讨论和审阅后才会被拉取合并。然而，Greg K-H 似乎刻意绕过了这部分流程，仅仅将补丁发送至流量最大、几乎不会有人认真阅读每封邮件的 [email protected] 列表，并于仅仅两天后就向 Linus Torvalds 发起拉取请求，而 Torvalds 亦未对相关修改提出质疑和意见便拉取合并这笔更改了。
考虑到 Linus Torvalds 与 Greg K-H 均受雇于 The Linux Foundation，后者为注册在美国的 501(c)(6) 组织，“某些合规性要求”为何显而易见。
截至发稿时，Greg K-H 尚未回应邮件列表上的相关质询。无论结果为何，这都将是 Linux 内核社区历史上最为耻辱的提交之一。
在这一风波伊始，我社贡献者柯晓宇采取了非常勇敢的行动，在提出撤回补丁 (Revert) 的同时，据理力争表达了自己的不满与质疑。⁴ 与此同时，我们的贡献者密切地关注着这个话题，我们都抱有一丝似有似无的希望：“Greg Kroah-Hartman 和 Linus Torvalds 是否正迫于难以言状的政治压力才做出如此令人意外的事情？”
很不幸的是，在 Greg Kroah-Hartman 选择违反 Linux 邮件列表网络礼仪与列表中的多人私下交涉后 ⁵，Linus Torvalds 直接选择了最令人不齿的方式回应质疑——攻击、侮辱和诋毁我社贡献者 ⁶ ：
It's entirely clear why the change was done, it's not getting reverted, and using multiple random anonymous accounts to try to "grass root" it by Russian troll factories isn't going to change anything.
为什么要这样改原因很明确，我们也不会撤回这个提交。就算这样用一堆俄罗斯巨魔工厂里整来的匿名账号群起而攻之，结果也不会改变。
Linus Torvalds 还提到，“无辜的路人们”应当理解 Greg Kroah-Hartman 所指的“某些合规性要求”并非美国专利。他还指出，不了解什么是对俄制裁的读者有空应该“多读新闻”。
而后，Linus Torvalds 话锋一转，攻击由柯晓宇提交的关于撤回变更的补丁：
As to sending me a revert patch - please use whatever mush you call brains. I'm Finnish. Did you think I'd be *supporting* Russian aggression? Apparently it's not just lack of real news, it's lack of history knowledge too.
至于前面发来的撤回补丁，请用一用你们那坨可能叫做脑子的东西。我是芬兰人，你们觉得我可能会支持俄国的侵略吗？显然你们不光没读过真实的新闻，还对历史一无所知。
在如今地缘政治极端紧张的今天，Linus Torvalds 选择使用国籍囊括政治观点的行为极端不负责任。更不用说将社区的一切反对意见都归结为“俄罗斯巨魔”和吸取“俄罗斯国家赞助的垃圾信息”的后果。Linus Torvalds 的发言无疑将为 Linux 内核及国际开源社区的协作互信，乃至全人类自由与开源软件运动带来难以弥补的损害。
因上述事由，我们对 Linux 基金会职员、乃至该组织的不当行为表示强烈抗议和谴责。我们要求 Linux 基金会就 Linus Torvalds 及 Greg Kroah-Hartman 的行为作出解释并对所有相关人员致歉并恢复名誉。
—
¹ https://lore.kernel.org/all/2024101835-tiptop-blip-09ed@gregkh/
² https://lore.kernel.org/all/[email protected]/
³ https://lore.kernel.org/all/[email protected]/
⁴ https://lore.kernel.org/all/[email protected]/
⁵ 我社贡献者白铭骢在认定 Greg Kroah-Hartman 的私下沟通全无诚意且具有侮辱性后选择公开邮件对话全文 https://lore.kernel.org/all/[email protected]/
⁶ https://lore.kernel.org/all/CAHk-=whNGNVnYHHSXUAsWds_MoZ-iEgRMQMxZZ0z-jY4uHT+Gg@mail.gmail.com/
费流:
南方航空B-1243号机（B787-9，制造商编号63979，产线编号699，事发时机龄6.5年）执行上海虹桥-广州CZ3534航班，副驾驶预先准备时曾向教员提出练习无指引盲降，教员评估广州天气后同意。机组在四边高度保持900米，得到进近许可后脱开自动驾驶，教员关闭两侧指引仪后，打开左侧指引仪，按压APP。飞机在副驾驶人工操纵下建立02L跑道盲降，五边进近期间，飞行参数基本正常。进跑道前，飞机偏高， 机组小幅推杆修正。进跑道后，飞机下沉偏快， 左座教员上手拉杆。随后飞机接地，接地后副驾驶拉出反推同时飞机出现轻微跳，弹起高度大约3英尺，机组继续向后拉杆，随后飞机再次接地。副驾驶继续拉出反推，飞机正 常减速。脱离跑道后机组发现触发EICAS信息AUTO THROTTLE DISC (自动油门断开)及TAIL STRIKE (擦机尾)，到位后机组报告机务擦机尾，机务检查发现机尾有擦刮痕迹，后机身下部蒙皮大面积擦伤，目视可见蒙皮有一条裂纹，散货舱内部结构发现多处隔框断裂。飞行数据显示，飞机第一次接地姿态5°，垂直载荷1.36G，第二次接地姿态7.6°，垂直载荷2.47G。
这是今天的事？
Oryon这核心本来也不是target手机这个功耗区间，能效不好看很正常。再加上ARM现在也不是吃干饭的，X925和Oryon谁更优秀还真不好说。主要是我觉得不用ARM的东西有很多SoC上的东西可以搞了，各种拓扑等。
果然不出所料，量产机的高通SD8E的Oryon大核对D9400 X925的优势比前些年大家都用公版时高通对mtk的优势还要小；中核更是作为一个N3E核心，在能效曲线里全程贴着N4P的SD8 gen 3的A720走。
高通这代自研核心的优势大概是体现在名字更好听这方面。
高通这代自研核心的优势大概是体现在名字更好听这方面。
Chips and Cheese
Running SPEC CPU2017 on Chinese CPUs, and More
#ChipAndCheese
Telegraph | source
(author: Chester Lam)
Running SPEC CPU2017 on Chinese CPUs, and More
#ChipAndCheese
Telegraph | source
(author: Chester Lam)
Harry Chen’s Blog
glibc 的特性（features）宏与其对 ABI 兼容性的影响
Telegraph | source
(author: Shengqi Chen ([email protected]))
glibc 的特性（features）宏与其对 ABI 兼容性的影响
Telegraph | source
(author: Shengqi Chen ([email protected]))
Chips and Cheese
AMD's Turin: 5th Gen EPYC Launched
#ChipAndCheese
Telegraph | source
(author: George Cozma)
AMD's Turin: 5th Gen EPYC Launched
#ChipAndCheese
Telegraph | source
(author: George Cozma)
杰哥的{运维，编程，调板子}小笔记
IBM z15 Mainframe CPU 分支预测器学习笔记¶
背景¶
ISCA 2020 的一篇文章 The IBM z15 High Frequency Mainframe Branch Predictor Industrial Product 非常详细地解析了 IBM z15 Mainframe CPU 的分支预测器设计。本文是对这篇论文的学习和整理的笔记。
设计思路¶
论文的第二节 Branch Prediction Design Considerations 提到了它设计分支预测器时需要考虑的事情。z15 处理器面向的是具有很大指令 footprint 的程序，为此准备了 128KB 的 L1 ICache，以及 4MB 的 L2 Private ICache。为了支撑 MB 级别的指令，BTB 也要相应增大。
IBM z 系列用的是变长指令集，指令长度可能是 2 或 4 或 6 字节，平均长度是 5 字节。考虑到每 5 条指令有一条分支指令，那就是每 25 个字节有一条分支指令，那么 4MB 的 L2 ICache 平均下来可能有 164K 条分支。因此，z15 设计了可以保存 128K 条分支的 L2 BTB。z15 的流水线很长，分支预测错误会带来 26 个周期的开销，因此分支预测的正确率就很重要。z15 处理器设计了两级的 BTB，L1 BTB（论文中称 BTB1）容量是 16K=2K x 8 way，L2 BTB（论文中称 BTB2）容量是 128K=32K x 4-way。为了加速 L1 BTB 的预测，z15 有 Column Predictor（CPRED，1K x 8）。为了预测分支的方向，z15 还引入了 PHT（short 和 long 两个 PHT，都是 512 x 8），Perceptron（16 x 2）。为了预测间接分支和返回指令的目的地址，z15 设计了 Changing Target Buffer（CTB，2K x 1）和 Call/Return Stack（CRS）。
具体实现¶
z15 采用的是分离式前端，分支预测器有 6 级的流水线，每一级分别记为 b0-b5。各级的功能如下：
z15 的 L1 BTB 的 8-way 意味着在一个周期可以进行 8 条分支的预测，从 64B 的指令中，识别最多 8 条指令，从中找到第一条跳转的分支。为了优化性能和功耗，在面对连续的无分支指令的代码时，可以快速跳过，这里用的是 SKOOT（Skip Over OffseT）预测器，在 BTB 的分支记录了到下一次分支的距离，如果这个距离很长，那就可以快速跳过若干个 64B 指令块。
为了预测分支的方向，在 L1 BTB 里，也保存了 2 bit saturating counter，也就是 BTB 也充当了通常说的 BHT。除了 BHT 以外，为了预测分支方向，z15 记录了 Global Path Vector，也就是常说的 PHR，记录最近的 n 条 taken branch 的历史。z14 之前，GPV 记录了最近 9 条 taken branch 的历史，z14 和 z15，GPV 记录了最近 17 条 taken branch 的历史。GPV 中每个 taken branch 提供 2 bit 的信息。
GPV 和 PC 作为 TAGE 的输入，进行方向预测。z15 采用了两个 TAGE PHT，都是 512 x 8 way，一共是 8K 分支的容量，历史短的 TAGE PHT 只用最近 9 条 taken branch 的历史，历史长的 TAGE PHT 则会用完整的 17 条 taken branch 的历史。论文里比较详细地描述了 TAGE 的实现，基本和 A. Seznec 的设计是一样的，也做了 USE_ALT_ON_NA 的改进。除了 TAGE 以外，z15 还有 Perceptron 预测器，有 32 个 entry，16 x 2 way，把系数和 GPV 进行点积（GPV 的每个 bit 映射为 1 和 -1），根据结果的符号决定跳转的方向。
因此一共有 BHT、TAGE 和 Perceptron 可以提供方向预测。为了判断用哪个预测器来提供最终的方向，规则是：
1. 对于条件分支，记录它是否曾经跳和不跳过（Bidirectional），如果只往一个方向跳，就查 BHT
2. 如果两个方向都跳过，此时 Perceptron 优先级更高，如果 Perceptron 命中且置信度高，则用 Perceptron 的结果
3. 否则考察 TAGE 的预测结果，如果 TAGE 命中且置信度高，则用 TAGE 的结果
4. 如果 Perceptron 和 TAGE 都没有命中，再用 BHT 的结果
简单来说，优先级是 Perceptron > TAGE > BHT。
为了预测间接分支的目的地址，z15 上 PC 和 GPV 通过哈希映射到 CTB（Changing Target Buffer）的表项上，每个表项记录了分支的目的地址。
有意思的是，z15 指令集里没有单独的 call 和 return 指令，因此硬件需要识别间接分支里的 call 和 return 模式。论文里介绍了具体的识别方法，但目前主流指令集都做了区分（要么是单独的指令，要么建议编译器用特定的寄存器，标记 call 和 return），所以这个方法也没啥参考价值。
source
IBM z15 Mainframe CPU 分支预测器学习笔记¶
背景¶
ISCA 2020 的一篇文章 The IBM z15 High Frequency Mainframe Branch Predictor Industrial Product 非常详细地解析了 IBM z15 Mainframe CPU 的分支预测器设计。本文是对这篇论文的学习和整理的笔记。
设计思路¶
论文的第二节 Branch Prediction Design Considerations 提到了它设计分支预测器时需要考虑的事情。z15 处理器面向的是具有很大指令 footprint 的程序，为此准备了 128KB 的 L1 ICache，以及 4MB 的 L2 Private ICache。为了支撑 MB 级别的指令，BTB 也要相应增大。
IBM z 系列用的是变长指令集，指令长度可能是 2 或 4 或 6 字节，平均长度是 5 字节。考虑到每 5 条指令有一条分支指令，那就是每 25 个字节有一条分支指令，那么 4MB 的 L2 ICache 平均下来可能有 164K 条分支。因此，z15 设计了可以保存 128K 条分支的 L2 BTB。z15 的流水线很长，分支预测错误会带来 26 个周期的开销，因此分支预测的正确率就很重要。z15 处理器设计了两级的 BTB，L1 BTB（论文中称 BTB1）容量是 16K=2K x 8 way，L2 BTB（论文中称 BTB2）容量是 128K=32K x 4-way。为了加速 L1 BTB 的预测，z15 有 Column Predictor（CPRED，1K x 8）。为了预测分支的方向，z15 还引入了 PHT（short 和 long 两个 PHT，都是 512 x 8），Perceptron（16 x 2）。为了预测间接分支和返回指令的目的地址，z15 设计了 Changing Target Buffer（CTB，2K x 1）和 Call/Return Stack（CRS）。
具体实现¶
z15 采用的是分离式前端，分支预测器有 6 级的流水线，每一级分别记为 b0-b5。各级的功能如下：
Indexing into the BTB arrays occurs inthe b0 cycle, which when superimposed over the z15 corepipeline in figure 1 coincides with the very stage after arestart, but deviates away from the core pipeline after that.An array access cycle is in b1. Metadata from the arrays isobtained in b2, and hit detection and direction applicationon a per branch basis performed across the b2 and b3cycles. Ordering of the branches based on their low-orderinstruction address bits is also done in b3. In b4, the finalprediction is prepared, including selection of theappropriate target address provider. The prediction ispresented to the consumers, namely the IDU and ICM, inthe b5 cycle.如果等到 b5 才出预测结果就比较慢了，因此它还可以在 b2 周期出结果，利用的是 CPRED 预测器。在 CPRED 工作的情况下，每两个周期可以预测一个 taken branch，如果 CPRED 没有预测，那就需要每 5 个周期预测一个 taken branch，而在 SMT2 模式下，两个线程轮流访问 BTB，此时每个线程需要每 6 个周期预测一个 taken branch。
z15 的 L1 BTB 的 8-way 意味着在一个周期可以进行 8 条分支的预测，从 64B 的指令中，识别最多 8 条指令，从中找到第一条跳转的分支。为了优化性能和功耗，在面对连续的无分支指令的代码时，可以快速跳过，这里用的是 SKOOT（Skip Over OffseT）预测器，在 BTB 的分支记录了到下一次分支的距离，如果这个距离很长，那就可以快速跳过若干个 64B 指令块。
为了预测分支的方向，在 L1 BTB 里，也保存了 2 bit saturating counter，也就是 BTB 也充当了通常说的 BHT。除了 BHT 以外，为了预测分支方向，z15 记录了 Global Path Vector，也就是常说的 PHR，记录最近的 n 条 taken branch 的历史。z14 之前，GPV 记录了最近 9 条 taken branch 的历史，z14 和 z15，GPV 记录了最近 17 条 taken branch 的历史。GPV 中每个 taken branch 提供 2 bit 的信息。
GPV 和 PC 作为 TAGE 的输入，进行方向预测。z15 采用了两个 TAGE PHT，都是 512 x 8 way，一共是 8K 分支的容量，历史短的 TAGE PHT 只用最近 9 条 taken branch 的历史，历史长的 TAGE PHT 则会用完整的 17 条 taken branch 的历史。论文里比较详细地描述了 TAGE 的实现，基本和 A. Seznec 的设计是一样的，也做了 USE_ALT_ON_NA 的改进。除了 TAGE 以外，z15 还有 Perceptron 预测器，有 32 个 entry，16 x 2 way，把系数和 GPV 进行点积（GPV 的每个 bit 映射为 1 和 -1），根据结果的符号决定跳转的方向。
因此一共有 BHT、TAGE 和 Perceptron 可以提供方向预测。为了判断用哪个预测器来提供最终的方向，规则是：
1. 对于条件分支，记录它是否曾经跳和不跳过（Bidirectional），如果只往一个方向跳，就查 BHT
2. 如果两个方向都跳过，此时 Perceptron 优先级更高，如果 Perceptron 命中且置信度高，则用 Perceptron 的结果
3. 否则考察 TAGE 的预测结果，如果 TAGE 命中且置信度高，则用 TAGE 的结果
4. 如果 Perceptron 和 TAGE 都没有命中，再用 BHT 的结果
简单来说，优先级是 Perceptron > TAGE > BHT。
为了预测间接分支的目的地址，z15 上 PC 和 GPV 通过哈希映射到 CTB（Changing Target Buffer）的表项上，每个表项记录了分支的目的地址。
有意思的是，z15 指令集里没有单独的 call 和 return 指令，因此硬件需要识别间接分支里的 call 和 return 模式。论文里介绍了具体的识别方法，但目前主流指令集都做了区分（要么是单独的指令，要么建议编译器用特定的寄存器，标记 call 和 return），所以这个方法也没啥参考价值。
source
