• 👋 你好，欢迎来到云栖梦泽 随机一篇文章

    须知少时凌云志·曾许人间第一流

    一个专注于设计思考与生活探索的独立博客！记录设计灵感、分享生活火花。 用设计思维解构日常之美。

    • 林渡

      蟹黄汤包和河豚还得是靖江的好吃！ 南通的海鲜也是鲜到眉毛了！

    • 林渡

      看了好久，还是狠心下手了小牛mt sport 2026款，以后可以下班送外卖了 - 。 -

    • 林渡

      想通了，工具是我的，能力是我的，公司只是一段时间的甲方。

    • 林渡

      太痛了😭

    • 林渡

      我爱白嫖！

    • 林渡

      这段时间我写博文的速度也慢下来了，因为我在思考，思考在这个AI时代下技术博客还有没有必要存在？ 从我个人角度来说，我其实也不愿意看那些长篇大论的技术文章，也是随手丢给 AI 看一眼，让它帮我总结提炼出关键！而我遇到的那些坑，其实 AI 也比我更加的懂，更加的全面，那我还有必要写嘛？

  • 📢 致读者的一封信：关于运营、初心与一份邀请

    林渡在博客中坦诚分享了Android稳定性与Linux内存管理等技术经验，强调知识共享与技术传承的重要性。尽管维持博客运营需承担服务器、域名、AI工具等实际成本，他坚守不设付费墙，保持全部内容免费开放，以降低技术门槛并营造纯粹交流空间。为回应读者建议，新增自愿捐赠通道与透明捐赠者名单，仅供愿意支持的朋友参与。每一份支持都将用于提升博客体验与内容质量，但无论捐赠与否，所有人都是这个温暖技术社区的重要参与者。

  • 站在2025的尾巴上：回顾、感恩与前行

    2025年，作者在人生与职业的双重转折中，聚焦于“尝试平衡”。工作上勇于转型，持续分享与协作，实现技术与心态的成长；生活中，婚姻和家庭成为新的关注重心。通过经验总结、系统学习和乐于成就他人，收获个人成长，体会到快速学习和适应变化是核心能力，并在自我反思中展望未来。

  • [linux内存管理] 第000篇 Linux内存管理系列开篇

    系列深入剖析Linux内存管理在ARM64架构下的原理与实现，覆盖物理内存初始化流程、核心分配器机制（如buddy、slab、vmalloc、CMA等）、缺页异常处理、页面回收、内存节点解析等关键环节，结合Kernel 5.15源码与丰富补充资料，帮助读者系统理解底层架构与内存管理优化要点

    • Linux内存管理
      [linux内存管理] 第 054 篇 OOM触发 + Memory Reserve + out_of_memory 决策

      本文深入解析Linux内存管理中OOM（内存溢出）的触发机制与决策流程。文章聚焦于从内存分配失败到系统响应的关键链路，涵盖OOM触发的三条路径、作为最后防线的Memory Reserve（32页保留内存）机制，以及out_of_memory()全局入口的决策内幕。通过对核心数据结构oom_control及具体调用链的分析，揭示了内核在内存耗尽时如何从回收自救逐步走向进程查杀的全过程。

      [linux内存管理] 第 054 篇 OOM触发 + Memory Reserve + out_of_memory 决策
    • Linux内存管理
      [linux内存管理] 第 053 篇 OOM 整体流程：从内存耗尽到系统崩溃的完整链路

      本文详细解析了Linux内核中OOM（内存不足）机制的完整处理流程。当系统内存耗尽且所有回收手段（如直接回收、kswapd、内存规整）均告失败后，内核会触发OOM处理。文章介绍了OOM的定位（回收失败后的最终策略）及其主要触发场景，包括全局内存不足和cgroup（memcg）内存限制等。核心在于系统必须决定是否终止进程、选择哪个进程作为牺牲者，以及在极端情况下是否触发系统恐慌。

      [linux内存管理] 第 053 篇 OOM 整体流程：从内存耗尽到系统崩溃的完整链路
    • 灵感风暴 / 与AI共生
      LoreMate：给 lore.kernel.org 装上 AI 阅读助手

      LoreMate 是一款面向 lore.kernel.org 的 Chrome AI 扩展，旨在解决内核邮件列表信息庞杂、难以追踪的核心痛点。它通过提供线程智能摘要、补丁系列解析、风险点检测和一键拉取等功能，充当“阅读副驾”，帮助开发者快速理解讨论上下文、追踪补丁状态并连接本地工作流，从而显著降低参与内核开发的门槛。

      LoreMate：给 lore.kernel.org 装上 AI 阅读助手
    • 技术分享
      AOSP 整机源码 Harness 工程探索

      本文探讨了在庞大的AOSP整机源码树（如AOSP 17）中使用Claude Code等Coding Agent所面临的导航困难、上下文不足等核心挑战。文章分析了现有方案，并详细介绍了作者构建的一套四层harness工程。该工程旨在帮助Agent在千万行代码的复杂仓库中稳定地完成导航、编译、部署和验证等任务，最终目标是在Cuttlefish虚拟机上实现有效的自动化开发。

      AOSP 整机源码 Harness 工程探索
    • Linux内存管理
      [linux内存管理] 第 052 篇 shrink_page_list：内存回收的“最后一道关口”

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

      [linux内存管理] 第 052 篇 shrink_page_list：内存回收的“最后一道关口”
    • 与AI共生
      Monsoon Power Monitor MCP 工具介绍

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

      Monsoon Power Monitor MCP 工具介绍
    • Linux内存管理
      [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内存管理] 第 051 篇 内存回收核心 shrink_node
    • Linux内存管理
      [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内存管理] 第 050 篇 深度分析 direct reclaim 机制
    • Linux内存管理
      [linux内存管理] 第 049 篇 深度分析 Linux kswapd 后台回收机制

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

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

精选分类

our mind

走心评论

our time

共赴十年之约