2026 年 - 云栖梦泽

[linux内存管理] 第 052 篇 shrink_page_list：内存回收的“最后一道关口”

shrink_page_list 是 Linux 内核内存回收机制的最终执行层。它负责从 LRU 链表取出待回收页面，并逐个做出“回收”或“保留”的判决，将决定回收的页面真正释放到伙伴系统。该函数位于整个回收调用链的末端，是内存释放的实际操作者，其决策过程包含了页面锁、访问引用、脏页写回等多项关键检查。

Monsoon Power Monitor MCP 工具介绍

Monsoon Power Monitor MCP 是一个面向功耗测试自动化的本地工具，将硬件控制能力封装为可自然语言调用的接口。它通过 MCP Server 和 Windows Helper 两层架构，支持自动连接设备、控制供电、采样及数据导出，旨在将功耗测试从手工操作推进到脚本化、可复用且可接入智能体的自动化流程。未来可扩展至回归测试、异常识别及结构化报告生成，为功耗分析提供底层能力。

[linux内存管理] 第 051 篇内存回收核心 shrink_node

shrink_node 是 Linux 内存回收路径的核心枢纽：无论是 kswapd 后台回收，还是 direct reclaim / node_reclaim 这种前台、同步回收，最终都汇聚到这个函数，在节点维度完成真实的页面回收调度。文中用结构化示意图清晰展开 shrink_node 的调用链：上游由 kswapd_shrink_node（后台回收）、shrink_zones（try_to_free_pages 路径的 direct reclaim）以及 __node_reclaim（快速 node_reclaim 同步回收）等入口触发；下游则分流到 shrink_node_memcgs、

[linux内存管理] 第 050 篇深度分析 direct reclaim 机制

直接回收是 Linux 内存分配慢路径中的同步回收机制：当 kswapd 的后台回收跟不上分配需求、快路径已失败时，由分配线程“自己动手”回收页面，作为介于 kswapd 与 OOM 之间的第二道防线。整体流程发生在 __alloc_pages_slowpath 中：先尝试唤醒 kswapd 和常规分配，再进行内存压缩和预留内存使用，关键的第四阶段是 __alloc_pages_direct_reclaim，通过 __perform_reclaim 调用 try_to_free_pages 做实际回收，然后再用 get_page_from_freelist 重试分配；若仍失败，则一次性释放 H

[linux内存管理] 第 049 篇深度分析 Linux kswapd 后台回收机制

在上一节整体梳理内存回收机制之后，本篇聚焦“内脏细节”，系统性拆解 Linux 内核中实际扫描与释放页面的关键链路。文章围绕 kswapd 后台回收与直接回收两大路径展开：一条从 kswapd() → balance_pgdat() → shrink_node()，解析内核回收线程何时被唤醒、在何种回收程度下停止，以及它与页面分配器之间如何协同保持内存水位；

[linux内存管理] 第 048 篇从 alloc_pages() 开始：快慢路径下的内存回收策略

本文深入剖析了Linux内核内存回收的触发机制。当应用程序通过`alloc_pages()`请求内存时，若快速路径（从空闲列表获取）失败，便会进入慢速路径。慢速路径会根据情况唤醒`kswapd`后台内核线程进行异步回收，或在内存极度紧张时执行同步的直接回收。文章通过详细的调用流程图，清晰地展示了从分配入口到具体回收操作（如页面扫描、交换、释放）的完整路径，阐明了内核如何通过这种分层策略来平衡性能和内存可用性。

[linux内存管理] 第 047 篇 Linux 内存回收（Memory Reclaim）总体架构

Memory Reclaim 是 Linux 内存管理的重要组成部分，也是理解内核内存管理的关键。本文以 Linux 5.15 为主线，从整体架构的角度梳理 Memory Reclaim 的工作流程、核心模块及源码结构，为后续深入分析页面回收机制做好铺垫。

[Android稳定性] 第065篇 SELinux 设置为 permissive 模式后出现的 kernel panic

项目在 bringup 阶段发现，将手机 SELinux 设为 permissive 后系统会在进入 Android 前死机。通过 fulldump 与内核日志可见 panic 原因是 UBSAN 报告的数组越界，触发点位于 uzram 模块的 zram_submit_bio。借助自研工具 kernel-panic-killer，AI 自动还原异常路径：反汇编发现 zram_submit_bio 中通过 current_algo 计算压缩算法索引，逻辑为 algo = current_algo; 访问 zram->comps[algo - 1]。由于 current_algo 默认为未初始化的

再看《孩子王》观后感：当AI成为每个人的“字典”之后

本文通过重看电影《孩子王》，将其核心道具“字典”与当下的AI工具进行类比。作者指出，学生王福渴望字典，如同今天人们依赖AI直接获取答案，两者本质都是知识工具。文章核心观点在于，关键并非工具本身，而是使用工具的过程：传统的查证、试错与思考过程正在被AI省略，这可能导致“不再需要思考”的风险。作者借此呼吁，应将AI视为辅助理解的工具，而非思考的替代品。

[Android稳定性] 第064篇 blk_mq_tags Use-After-Free 导致系统级 I/O 死锁

围绕 SPRD UMS9230 平台在 DDR Qualify.TT 测试中出现的冻屏问题，分析通过 ramdump、vmlinux 等工件定位到根因在内核 Block 层：blk_mq_tags 结构体发生 use-after-free，Scsi_Host.tag_set.tags 指针指向已被释放并被 cpumask/IRQ affinity 对象重用的 kmalloc-128 slab。内存中出现 “effective_affinity” 字符串，进一步印证该区域已被 IRQ 亲和性相关对象覆盖。由于 blk_mq_hw_ctx.tags 和 sched_tags 均为 NULL，当 E

[Android稳定性] 第063篇 EROFS 解压缩页面 Use-After-Free 导致 Kernel Panic

围绕一次发生在 Qualcomm Ravelin SNP-AN00 平台上的 kernel panic，分析聚焦于 EROFS 压缩文件系统在 LZ4 解压过程中出现的 translation fault。根因是函数 z_erofs_lz4_decompress_partial 通过 __memcpy 访问压缩源页时，源页与目标页已被 page allocator 释放并填充为标准毒化值 dead000000000400，形成典型的 use-after-free。

[开源项目] GitNexus + Claude Code 配置与使用指南

GitNexus 是一款将代码仓库自动索引为知识图谱的工具，它会追踪项目中的每个依赖、调用链、集群和执行流，并通过 MCP（Model Context Protocol）暴露给 Claude Code，使 AI 代理真正理解代码的全局架构与复杂关系。在实际开发场景中，GitNexus 的核心价值体现在四个方面：让 AI 在分析和修改代码时不再遗漏隐含依赖和调用链；在改动代码前，可以准确评估变更的“爆炸半径”，降低引入潜在 bug 的风险；调试时能沿着调用链快速锁定错误源头，节省排查时间；进行重构和多文件重命名时更安全可控，减少对线上系统的影响。

2026 年 9 月
日	一	二	三	四	五	六
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30