加载失败
这篇讨论围绕一篇关于 Linux 内核某次 preemption 改动的文章展开，文章声称 PostgreSQL 在特定基准测试里出现了明显回退。评论补充说，问题大概率只出现在非常特殊的配置：超大内存、关闭 hugepages，而且可能还是 ARM 平台，表现出来的主要是锁竞争变差，而不是 PostgreSQL 在所有场景都失效。LKML（Linux Kernel Mailing List，Linux 内核邮件列表）上的争论进一步延伸到 hugepages 是否该默认开启，以及新 kernel 和旧应用混用时会不会在 container 和生产环境里悄悄变慢。更大的背景是，内核社区经常需要在“某个 workload 变慢”和“另一些场景受益”之间做取舍，所以这类回归是否值得回退总会引发争议。
不少评论认为，这次更像是一个边缘配置下的性能回退，而不是 PostgreSQL 在所有环境里都“被破坏”了。有人明确要求先看真实生产负载是否真的受影响，再决定要不要回退 kernel 改动，因为一个基准测试变慢并不自动意味着系统整体失效。评论里也有人指出，标题把问题说得过于宽泛，实际只出现在很特殊的条件下。
讨论焦点很快转到 hugepages：触发问题的场景被描述为 120GB RAM 的 PostgreSQL，且 hugepages=off 时 lock contention 变得更糟。有人说很多人因为历史包袱习惯性关闭 hugepages，但它其实早已稳定，尤其对大内存数据库常常有明显收益。还有人分享在 Azure VM 上跑 pgbench 时获得了 10–15% 的提升，并猜测这可能只在 ARM 或特定 AWS（亚马逊云）自定义 kernel 上出现。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
另一种看法是，内核性能回退本身就等于功能退化，因为用户感受到的是实际吞吐下降，而不是代码层面的“没坏”。特别是在 container 里，可能会出现新 kernel 配旧 PostgreSQL 的组合，应用端并没有现成的补救代码。按这个逻辑，哪怕没有 API break，X% 的变慢也会直接变成生产环境里的用户态问题。
评论还延伸到 Linux 社区文化：有人觉得 Linus 应该再“吼”一次，因为能把补丁送到主线的通常是资深开发者，出错就该承担更严厉的反馈。也有人反对这种公开羞辱，认为它会让好意贡献者感到挫败，甚至把有能力的人赶远。这个分歧本质上是在讨论，Linux 维护质量和贡献者体验之间到底该怎么平衡。
hugepages: 比普通 memory page 更大的页，能减少页表和 TLB 开销，常用于大内存数据库。
preemption: 内核抢占机制，允许调度器打断当前任务以提升响应性，但也可能改变某些负载的吞吐和延迟表现。
lock contention: 多个线程或进程争用同一把锁，导致等待时间增加并引发性能下降。