[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fRNeuN64miV_UbkrEYN92QujGA5_xt_jTFT1-8t_OaHc":3},{"item":4,"related":44},{"id":5,"type":6,"title":7,"slug":8,"summary":9,"body":10,"coverUrl":11,"productScreenshots":12,"productLinks":13,"authorName":14,"authorUrl":15,"authorSubject":16,"category":17,"tags":22,"sourceLabel":35,"sourceName":36,"sourceUrl":37,"status":38,"seoTitle":7,"seoDescription":9,"canonicalUrl":35,"isFeatured":39,"sno":40,"sortOrder":41,"publishedAt":42,"updatedAt":43,"createdAt":43},"96518024-83a1-47ae-b61d-bebf464c54a7","article","Transparent Huge Pages：大页能省 TLB，为什么有时又会卡顿？","transparent-huge-pages-benefits-tradeoffs","透明大页用更大的内存映射减少地址转换管理成本，却可能带来分配、碎片和缺页开销。本文用通俗例子讲清它的适用场景与评估方法。","操作系统通常以“页”为单位管理内存。普通页尺寸较小，精细灵活，却意味着大内存工作集可能需要很多页表条目和地址转换。Transparent Huge Pages（THP，透明大页）尝试把一组相邻普通页合并为更大的映射，让处理器用更少的 TLB 条目覆盖更多内存，也有机会减少页表层级和管理负担。\n\n“透明”指应用程序通常不必改成另一套内存 API，内核可以在合适的时候尝试使用较大的页。可以把它想成把许多小储物格合并成大柜子：找东西时索引更少，管理结构也可能更精简。对持续访问大块内存的负载，这有机会减少 TLB 未命中和页表开销。它并非对所有程序都必然加速，而是操作系统与工作负载共同决定的优化机会。\n\n大页的另一面是粒度变粗。需要分配或清零更大块内存时，单次缺页处理可能更重；物理内存碎片也可能让内核难以找到合适的连续空间。若应用只改动大页中的很小一部分，复制或写时拆分可能增加额外工作。对延迟敏感的服务，偶发的内存整理、合并或缺页成本，可能比平均吞吐量更值得关注。\n\nTHP 与显式 HugeTLB 大页也不是一回事。前者强调内核透明地尝试合并和回退，通常可以在条件不合适时继续使用普通页；后者则是应用或管理员明确申请、管理的大页资源。透明不等于“内核永远会成功”，更不等于“所有进程都应该开启”。内核提供了不同策略和监控接口，实际行为还受系统配置、内存压力与内核版本影响。\n\n评估时应使用接近真实的负载，分别看吞吐、尾延迟、内存占用、缺页情况和碎片整理影响。只跑短小合成测试，可能看见 TLB 收益，却错过长时间运行后的抖动。若工作集很小，或访问模式并未受 TLB 限制，大页的收益可能有限；若负载规模大、访问密集，才值得进一步验证。对线上系统，先在隔离环境逐步测试，并保留回退路径。\n\nTHP 的价值不在于“大就是快”，而在于用更粗的页粒度换取地址转换效率，同时接受分配和管理成本。这是操作系统中很典型的工程权衡：自动优化减少应用改造，却仍需要用实际负载验证。\n\n来源：[Linux 内核文档：Transparent Hugepage Support](https:\u002F\u002Fdocs.kernel.org\u002Fadmin-guide\u002Fmm\u002Ftranshuge.html)","\u002Fuploads\u002F2026-10-06\u002Fb6f3a8bf-69b8-4eb9-bd54-2653607286fc.jpg",[],[],"Foundit","https:\u002F\u002Ffoundit.cn","foundit-ai-editorial",{"id":18,"name":19,"slug":20,"description":21},"6179d3b6-dc34-4483-9ded-3cd9f1b37a47","科普","abbreviation","介绍各领域新兴概念",[23,27,31],{"id":24,"name":25,"slug":26},"144abe77-0dc6-4f66-a176-20bddb1c0bfa","编程","coding",{"id":28,"name":29,"slug":30},"7c76bfc2-f80f-4ee0-a95d-27bd8708b434","技术","slug",{"id":32,"name":33,"slug":34},"4c2bbea6-eab7-40a8-8447-1de478ff7749","分析","analyse",null,"Linux Kernel Documentation：Transparent Hugepage Support","https:\u002F\u002Fdocs.kernel.org\u002Fadmin-guide\u002Fmm\u002Ftranshuge.html","published",false,49,0,"2026-10-06T00:00:00.000Z","2026-10-06T07:51:18.812Z",[45,54,63],{"id":46,"type":6,"title":47,"slug":48,"summary":49,"coverUrl":50,"authorName":14,"sno":51,"publishedAt":52,"createdAt":53},"5e0c84da-6011-41e8-b1f7-726c8bf0b30a","RCU：读多写少的系统，为什么敢让读者几乎不加锁？","rcu-read-copy-update-explained","RCU 把共享数据的更新与旧版本回收拆开，让读者以极低成本读取，同时等待所有旧读者离开后再释放内存。本文用导览图解释它的读侧、宽限期与适用边界。","\u002Fuploads\u002F2026-09-26\u002F3398ce37-ca4f-4cc3-84b3-fe931d2f055d.jpg",41,"2026-09-27T00:00:00.000Z","2026-09-26T16:25:40.784Z",{"id":55,"type":6,"title":56,"slug":57,"summary":58,"coverUrl":59,"authorName":14,"sno":60,"publishedAt":61,"createdAt":62},"0bc79f1c-f305-4d64-a9f8-589d1d6da0b3","EEVDF：Linux 如何判断哪个任务“最该先用 CPU”？","eevdf-linux-fair-cpu-scheduling","EEVDF 是 Linux 调度器的一种公平调度思路：先判断任务是否获得了应有份额，再按虚拟截止时间安排运行机会。本文用共享厨房的比喻，解释它如何兼顾长期公平与短期响应，并澄清它并非硬实时保证。","\u002Fuploads\u002F2026-10-13\u002Fdc59d374-8c78-41ba-bdfe-a6f0e62ab246.jpg",43,"2026-10-13T00:00:00.000Z","2026-10-13T02:13:28.103Z",{"id":64,"type":6,"title":65,"slug":66,"summary":67,"coverUrl":68,"authorName":14,"sno":69,"publishedAt":52,"createdAt":70},"23b5596a-29ab-4ff8-8237-1fd34d8e0bd1","Seqlock：读者不加锁，为什么还能读到一份一致的数据？","seqlock-sequence-counter-explained","Seqlock 让读者先后读取序列号并在变化时重试，以校验快照是否被写者打断，适合读多写少且字段可安全复制的数据。","\u002Fuploads\u002F2026-09-26\u002Fe6a9caee-7551-469f-9b16-d27fcc97f034.jpg",44,"2026-09-26T16:25:51.305Z"]