我做了一个 Obsidian 插件：AI 伴读助手
作者为解决在Obsidian中频繁切换AI工具导致的阅读中断问题，开发了AI Reading Companion插件。该插件可将AI辅助功能集成到Obsidian侧边栏，自动读取当前笔记、选中内容或RSS文章的上下文，提供总结、结构解析、生成思维导图、提炼金句等八种一键式“伴读动作”，并支持自定义提示词，旨在实现流畅、不打断的沉浸式阅读体验。
评论
点赞
收藏[Linux 内存管理] 第 060 篇 交换空间完整生命周期：从 swapon 到 swapoff
本文详细分析了 Linux 交换空间从通过 swapon 激活到通过 swapoff 关闭的完整生命周期。核心内容涵盖交换空间的系统调用入口、数据结构初始化、页换出与换入的 I/O 路径、交换缓存管理以及最终的资源清理过程，并介绍了相关的核心源文件及其职责。
[linux内存管理] 第 059 篇 /proc/slabinfo 详解
本文详细介绍了Linux内核SLUB内存分配器中/proc/slabinfo文件的内容与实现原理。文章首先说明SLUB是默认的内核对象分配器，并解释了通用缓存（如kmalloc-*）与专用缓存（如dentry）的管理框架。核心内容围绕如何利用/proc/slabinfo排查slab内存泄漏问题，包括结合/proc/meminfo、识别异常kmem_cache、进行时间序列采样及使用调试工具等步骤。...
【Linux 内存管理】第 058 篇 从虚拟内存到 Swap —— 交换子系统整体架构
本文阐述了Linux交换（Swap）子系统的核心作用与架构。其核心观点是：Swap的根本意义并非简单地用磁盘空间扩展内存，而是为那些本身没有持久后备存储的“匿名页”（如堆、栈数据）提供一个临时的后援存储。当物理内存紧张时，系统可以将这些匿名页换出到Swap空间，从而腾出物理内存供更急需的进程使用，这是Linux内存回收机制的关键一环。而有文件后援的“文件页”则可直接丢弃，需要时再从文件重新读入。
SyzForge：把 syzbot 报告锻造成可复现的内核 Bug 调查流水线
SyzForge 是一个面向 Linux 内核 Bug 排查的开源多 MCP 系统。它旨在解决 syzbot 报告信息分散、调查流程断裂的痛点，将原始报告转化为结构化、可重复的工程流水线。系统由 SyzLens（证据采集）、KernelLab（构建复现）和 KernelMail（邮件工作流）三个服务组成，遵循“工具执行确定性动作，Agent 负责主观推理”的原则，以提升调查的可追溯性和效率。
[linux内存管理] 第 057 篇 OOM Kill 与 panic_on_oom —— 杀人的艺术与崩溃的抉择
本文深入解析Linux内核OOM（内存不足）处理机制的最终环节。核心内容包括：通过oom_kill_process函数处决选定的受害进程（victim），其流程涵盖检查进程退出状态、打印系统内存日志、处理cgroup组，并最终发送SIGKILL信号。同时，文章阐释了panic_on_oom参数的不同取值（0、1、2）如何决定系统在OOM时是终止进程还是触发内核崩溃，为系统管理员在稳定性与故障恢复间...
[linux内存管理] 第 056 篇 OOM Reaper：异步解除映射的幕后英雄
OOM Reaper是Linux内核为解决OOM kill后内存释放延迟问题而设计的异步清理机制。当进程被OOM killer选中后，可能因自身处于不可中断状态而无法及时释放内存。OOM Reaper通过独立的内核线程异步扫描并回收受害进程的页表和物理页，避免系统因等待进程退出而陷入僵局，确保内存能快速回收，有效防止了OOM场景下的系统饥饿。
[linux内存管理] 第 055 篇 OOM Killer 死亡名单算法
OOM Killer是Linux系统在内存耗尽时选择进程终止的机制。其核心算法oom_badness通过三道过滤（排除init进程和内核线程、检查cpuset、排除正在终止的进程）和一个打分过程，为所有可终止进程计算“死亡分数”。分数基于进程的RSS、页面交换使用量等内存占用指标，最终选择最高分的进程作为牺牲者，以最大化释放内存并最小化系统影响。该设计体现了在极端内存压力下的平衡策略与工程智慧。
[linux内存管理] 第 054 篇 OOM触发 + Memory Reserve + out_of_memory 决策
本文深入解析Linux内存管理中OOM（内存溢出）的触发机制与决策流程。文章聚焦于从内存分配失败到系统响应的关键链路，涵盖OOM触发的三条路径、作为最后防线的Memory Reserve（32页保留内存）机制，以及out_of_memory全局入口的决策内幕。通过对核心数据结构oom_control及具体调用链的分析，揭示了内核在内存耗尽时如何从回收自救逐步走向进程查杀的全过程。
[linux内存管理] 第 053 篇 OOM 整体流程：从内存耗尽到系统崩溃的完整链路
本文详细解析了Linux内核中OOM（内存不足）机制的完整处理流程。当系统内存耗尽且所有回收手段（如直接回收、kswapd、内存规整）均告失败后，内核会触发OOM处理。文章介绍了OOM的定位（回收失败后的最终策略）及其主要触发场景，包括全局内存不足和cgroup（memcg）内存限制等。核心在于系统必须决定是否终止进程、选择哪个进程作为牺牲者，以及在极端情况下是否触发系统恐慌。
LoreMate：给 lore.kernel.org 装上 AI 阅读助手
LoreMate 是一款面向 的 Chrome AI 扩展，旨在解决内核邮件列表信息庞杂、难以追踪的核心痛点。它通过提供线程智能摘要、补丁系列解析、风险点检测和一键拉取等功能，充当“阅读副驾”，帮助开发者快速理解讨论上下文、追踪补丁状态并连接本地工作流，从而显著降低参与内核开发的门槛。
AOSP 整机源码 Harness 工程探索
本文探讨了在庞大的AOSP整机源码树（如AOSP 17）中使用Claude Code等Coding Agent所面临的导航困难、上下文不足等核心挑战。文章分析了现有方案，并详细介绍了作者构建的一套四层harness工程。该工程旨在帮助Agent在千万行代码的复杂仓库中稳定地完成导航、编译、部署和验证等任务，最终目标是在Cuttlefish虚拟机上实现有效的自动化开发。
[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_f...
[linux内存管理] 第 050 篇 深度分析 direct reclaim 机制
直接回收是 Linux 内存分配慢路径中的同步回收机制：当 kswapd 的后台回收跟不上分配需求、快路径已失败时，由分配线程“自己动手”回收页面，作为介于 kswapd 与 OOM 之间的第二道防线。整体流程发生在 __alloc_pages_slowpath 中：先尝试唤醒 kswapd 和常规分配，再进行内存压缩和预留内存使用，关键的第四阶段是 __alloc_pages_direct_re...
[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 ...