<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[yuanmenghao]]></title><description><![CDATA[]]></description><link>https://blog.csdn.net/zhoucoolqi</link><language>zh-cn</language><generator>https://blog.csdn.net/</generator><copyright><![CDATA[Copyright &copy; zhoucoolqi]]></copyright><item><title><![CDATA[Linux 性能实战系列 - 附录 Valgrind介绍]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/159127668</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/159127668</guid><author>zhoucoolqi</author><pubDate>Mon, 16 Mar 2026 18:16:22 +0800</pubDate><description><![CDATA[Valgrind是一个动态二进制分析框架，主要包含三个核心工具：Memcheck（内存错误检测）、Callgrind（CPU性能分析）和Massif（堆内存分析）。Memcheck用于检测内存泄漏、越界访问等问题；Callgrind通过统计指令数分析函数调用关系和热点；Massif则追踪堆内存使用变化。三者共享Valgrind的二进制翻译框架，但功能各异，运行开销在5-50倍不等。典型使用流程是先Memcheck查内存错误，再用Callgrind找性能瓶颈，最后Massif分析内存占用。注意Memcheck]]></description><category></category></item><item><title><![CDATA[Horizon QAT 量化训练指南 - fx_mode.py 工作流程分析文档]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/158971986</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/158971986</guid><author>zhoucoolqi</author><pubDate>Thu, 12 Mar 2026 16:39:24 +0800</pubDate><description><![CDATA[本文档分析了Horizon QAT量化训练工具中fx_mode.py的工作流程。主要分为三个阶段：1)参数解析阶段处理用户输入的命令行参数；2)模型准备阶段根据stage参数创建MobileNetV2模型并加载ImageNet预训练权重；3)训练执行阶段准备CIFAR-10数据集并进行30个epoch的训练循环。文档详细展示了各阶段的执行流程，包括核心模块调用关系、数据预处理步骤和训练评估循环。通过流程图和模块清单，清晰呈现了从模型初始化到完整训练的全过程，为理解和使用该量化训练工具提供了详细指导。]]></description><category></category></item><item><title><![CDATA[Horizon QAT 量化训练指南]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/158960190</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/158960190</guid><author>zhoucoolqi</author><pubDate>Thu, 12 Mar 2026 09:02:16 +0800</pubDate><description><![CDATA[本指南介绍基于Horizon OpenExplorer平台的量化感知训练(QAT)完整流程，包含从浮点模型到部署模型的转换过程。主要内容包括：浮点模型训练、QAT训练、HBIR中间表示导出和HBM模型编译四个关键步骤，以及各阶段输出的模型格式特点。特别对比了QAT与PTQ两种量化方法的差异，并详细解释了INT8量化原理、量化参数(scale/zero point)等核心概念。通过MobileNetV2在CIFAR-10上的实验表明，QAT方法能有效保持模型精度，最终HBM模型体积压缩70%，推理速度达11,]]></description><category></category></item><item><title><![CDATA[WSL + Docker GPU 环境排查：NVIDIA-SMI couldn‘t find libnvidia-ml.so 问题分析与解决]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/158935480</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/158935480</guid><author>zhoucoolqi</author><pubDate>Wed, 11 Mar 2026 22:41:21 +0800</pubDate><description><![CDATA[本文分析了WSL+Docker环境下出现NVIDIA-SMI couldn't find libnvidia-ml.so错误的原因和解决方案。关键发现是当Docker镜像已包含/usr/lib/wsl/lib目录时，NVIDIA runtime会跳过GPU库挂载，导致容器无法访问GPU。解决方法是通过-v /usr/lib/wsl/lib:/usr/lib/wsl/lib手动挂载WSL GPU库，并设置LD_LIBRARY_PATH环境变量。文章详细介绍了问题排查步骤，包括检查WSL GPU状态、Docke]]></description><category></category></item><item><title><![CDATA[Linux 性能实战 | 第 17 篇续 strace 高级技巧与生产环境实战]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/158812720</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/158812720</guid><author>zhoucoolqi</author><pubDate>Sun, 08 Mar 2026 22:14:01 +0800</pubDate><description><![CDATA[本文深入介绍了Linux调试工具strace的高级使用技巧和生产环境实战经验。通过真实案例展示了strace在排查程序卡死、多进程跟踪、系统调用耗时分析等方面的应用，包括：1) 通过futex调用定位死锁问题；2) 使用-f参数跟踪子进程；3) -T参数分析系统调用耗时；4) -c参数统计调用频率；5) 跟踪exec过程排查外部命令调用问题。文章还对比了strace与ltrace、perf等工具的区别，并给出生产环境使用建议，如控制性能开销、输出到文件等。最后总结strace作为Linux工程师&quot;]]></description><category></category></item><item><title><![CDATA[Linux 性能实战 | 第 17 篇续 小白一文彻底掌握 strace（从入门到深入）]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/158812499</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/158812499</guid><author>zhoucoolqi</author><pubDate>Sun, 08 Mar 2026 22:02:48 +0800</pubDate><description><![CDATA[摘要：本文深入讲解Linux调试工具strace的使用方法和原理。strace通过跟踪系统调用，可以快速诊断程序问题，如CPU飙高、卡死、文件/网络异常等。文章通过真实案例展示strace排查配置文件错误、网络连接问题的过程，并解析其底层ptrace实现机制。虽然strace会影响性能(10-100倍)，但作为调试工具极为强大，能揭示程序与内核的所有交互。作者强调，熟练使用strace能显著提升排障效率，是Linux工程师必备技能。]]></description><category></category></item><item><title><![CDATA[Linux 性能实战 | 附录：深入理解 Valgrind 内存泄漏检测原理]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/158622531</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/158622531</guid><author>zhoucoolqi</author><pubDate>Tue, 03 Mar 2026 21:31:38 +0800</pubDate><description><![CDATA[Valgrind 内存泄漏检测的核心原理是基于可达性分析。当程序退出时，Valgrind 会扫描所有可能的指针来源（寄存器、线程栈、全局变量等），构建根指针集合，然后递归标记所有可达的堆内存块。未被标记的内存块被判定为&quot;definitely lost&quot;。检测过程包括：拦截malloc/free调用、维护分配记录表、执行根扫描和标记可达内存。Valgrind能区分四种泄漏类型：完全不可达（definitely lost）、间接丢失（indirectly lost）、可能丢失（possibl]]></description><category></category></item><item><title><![CDATA[Linux 性能实战 | 附录：内存泄漏定位体系对比：perf vs Valgrind vs Heap Profiler]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/158622454</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/158622454</guid><author>zhoucoolqi</author><pubDate>Tue, 03 Mar 2026 21:28:03 +0800</pubDate><description><![CDATA[本文对比了Linux系统中三种内存泄漏定位工具：perf、Valgrind和Heap Profiler。perf基于采样统计模型，能发现分配热点但无法确认泄漏；Valgrind通过生命周期追踪可精确判定未释放内存，但性能开销大；Heap Profiler则通过聚合分析存活内存来源，适合线上诊断。文章指出，完整的内存泄漏排查需要结合这三类工具：先用perf定位分配热点，再用Heap Profiler分析存活内存路径，最后用Valgrind验证泄漏。这种分层分析方法能有效构建系统化的内存问题定位体系。]]></description><category></category></item><item><title><![CDATA[Linux 性能实战 | 附录：深入理解 pmap：进程内存映射全解析]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/158581198</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/158581198</guid><author>zhoucoolqi</author><pubDate>Mon, 02 Mar 2026 17:52:06 +0800</pubDate><description><![CDATA[fill:#333;important;important;fill:none;color:#333;color:#333;important;fill:none;fill:#333;height:1em;pmap -XX 核心知识字段体系Size 虚拟大小勿直接用RSS 含共享会高估PSS 按比例分摊最准确Anonymous 匿名堆总量Pss_Dirty 脏页写入量内存类型识别Device=00:00 匿名映射Perm=rw-s 共享内存Perm=r-xp 代码段。]]></description><category></category></item><item><title><![CDATA[Linux 性能实战 | 附录：为什么 Linux 要使用写入时复制（COW）]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/158545147</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/158545147</guid><author>zhoucoolqi</author><pubDate>Mon, 02 Mar 2026 06:45:00 +0800</pubDate><description><![CDATA[Linux采用写入时复制（COW）机制来优化内存管理，其核心设计原则是&quot;先共享，按需复制&quot;。动态库加载时，只读的代码段和常量段在进程间共享，而可写的数据段仅在进程实际修改时才复制。这种延迟分配策略大幅降低内存占用 - 例如加载100个进程时，COW机制相比立即复制可节省97%内存。COW体现了Linux的三大设计哲学：最大化共享、延迟成本和page fault驱动资源分配，使得fork操作快速、动态库共享高效，系统能够运行更多进程。通过pmap或smem命令可验证动态库内存主要显示为sh]]></description><category></category></item><item><title><![CDATA[Linux 性能实战 | 附录：动态链接库的内存是共享的吗？深入理解 .so 如何影响进程内存占用]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/158544794</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/158544794</guid><author>zhoucoolqi</author><pubDate>Sun, 01 Mar 2026 22:17:33 +0800</pubDate><description><![CDATA[动态链接库的内存共享机制解析 摘要：Linux系统中动态链接库(.so)的内存占用分为共享与私有两部分。代码段(.text)和只读数据段(.rodata)是共享的，所有进程共用同一物理内存；而数据段(.data)和未初始化变量段(.bss)则是每个进程私有的。这种机制通过写时复制(Copy-on-Write)实现，既保证了进程隔离性，又大幅节省了内存资源。实际内存分析时，应关注PSS(按比例分摊的共享内存)而非RSS，才能准确评估真实内存占用。典型场景下，100个进程共享2MB的libc.so，实际内存占用]]></description><category></category></item><item><title><![CDATA[Linux 性能实战 | 附录：动态链接库是如何影响多个进程内存占用的？]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/158544240</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/158544240</guid><author>zhoucoolqi</author><pubDate>Sun, 01 Mar 2026 21:38:12 +0800</pubDate><description><![CDATA[摘要： Linux系统中，多个进程的RSS（常驻内存）可能显示较大值，但实际物理内存占用远低于预期，核心原因是**shared page（共享页）**机制。动态链接库（.so）通过mmap映射到进程地址空间时，会被缓存在page cache中，多个进程共享同一物理内存页，而非各自复制。RSS统计所有映射页（含共享），而PSS（按进程数均摊）和USS（独占内存）更反映真实占用。例如100个nginx worker（RSS各50MB）可能仅占800MB物理内存，因共享libc等库。工程中应优先参考PSS/USS]]></description><category></category></item><item><title><![CDATA[Linux 性能实战 | 附录：为什么OOM killer参考的是RSS而不是USS或者PSS]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/158471223</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/158471223</guid><author>zhoucoolqi</author><pubDate>Sat, 28 Feb 2026 07:00:00 +0800</pubDate><description><![CDATA[Linux OOM killer机制基于RSS而非PSS进行决策，因为RSS直接反映进程实际占用的物理页数量，而内核内存管理的最小单位就是物理页。RSS统计成本低且准确反映可释放内存量，而PSS计算复杂且无法用于实际释放决策。当系统内存耗尽时，OOM killer选择RSS最大的进程终止以释放最多物理页，而非按比例分摊的PSS。共享内存虽计入RSS但实际释放需等待所有映射进程退出。实用建议：分析内存用PSS，预测OOM风险看RSS和oom_score。]]></description><category></category></item><item><title><![CDATA[Linux 性能实战 | 附录：VSS、RSS、PSS、USS的区别]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/158471149</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/158471149</guid><author>zhoucoolqi</author><pubDate>Fri, 27 Feb 2026 21:34:38 +0800</pubDate><description><![CDATA[本文解析了Linux系统中四种内存指标(VSS/RSS/PSS/USS)的区别与适用场景： PSS最准确，按比例分摊共享内存，反映真实进程内存占用 USS表示进程独占内存，决定进程终止时可释放的内存 RSS包含共享内存会重复计算，常用于OOM分析但不够精确 VSS包含虚拟内存不反映实际使用 工程建议：内存分析优先看PSS，判断释放效果看USS，OOM场景看RSS，避免参考VSS。通过示例演示了PSS如何正确计算共享内存，解决了RSS重复计算的问题。]]></description><category></category></item><item><title><![CDATA[Linux 性能实战 | 附录：进程CPU使用率的计算]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/158471082</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/158471082</guid><author>zhoucoolqi</author><pubDate>Fri, 27 Feb 2026 21:31:39 +0800</pubDate><description><![CDATA[本文详细讲解了计算进程CPU使用率的工程方法，核心公式为CPU% = Δ(utime + stime)/Δtotal_cpu_time × NCPU × 100%。utime和stime的单位是clock ticks（通常1 tick=10ms），通过两次采样差值计算CPU时间消耗。文章介绍了两种计算方法：直接使用进程统计信息或参考系统全局CPU时间，并提供了Python实现示例。重点分析了utime和stime的工程意义：utime高表示计算密集，stime高反映系统调用频繁。最后指出top工具的原理就是]]></description><category></category></item><item><title><![CDATA[Linux 下高效管理 VS Code 进程：`kill` 与 `pkill` 的正确用法]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/158419788</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/158419788</guid><author>zhoucoolqi</author><pubDate>Thu, 26 Feb 2026 10:25:21 +0800</pubDate><description><![CDATA[Linux下高效管理VS Code进程指南 本文介绍了在Linux系统中管理VS Code进程的正确方法。针对VS Code卡死或残留进程问题，对比了kill和pkill命令的区别：kill针对特定PID，而pkill可按名称批量操作。解释了pgrep -i code输出大量PID的原因——VS Code的多进程架构和模糊匹配特性。提供了精准管理方案：用pgrep -x code查主进程，pkill -f &quot;/usr/share/code/code&quot;彻底关闭所有进程，并建议先SIGTER]]></description><category></category></item><item><title><![CDATA[从零开始：使用 Claude Code 打造字母消除游戏]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/158355958</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/158355958</guid><author>zhoucoolqi</author><pubDate>Tue, 24 Feb 2026 22:00:56 +0800</pubDate><description><![CDATA[本文记录了使用Claude Code AI工具开发字母消除游戏的全过程。首先介绍了Claude Code的功能特点，包括自然语言编程、代码生成调试等能力。详细说明了安装步骤（npm/pip安装）和配置OpenModel GLM大模型的方法。游戏开发部分展示了从需求描述到完整实现的流程：HTML/CSS/JS代码生成、字母掉落机制、键盘交互、分数系统、连击效果和粒子动画等功能的实现。文章还包含了调试优化过程（解决字母重叠、窗口适配等问题）和最终游戏效果展示（开始界面、游戏进行中、连击效果等截图）。整个项目约3]]></description><category></category></item><item><title><![CDATA[Linux 性能实战 | 第 19 篇：ftrace 内核跟踪入门 [特殊字符]]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/158045083</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/158045083</guid><author>zhoucoolqi</author><pubDate>Fri, 13 Feb 2026 23:16:21 +0800</pubDate><description><![CDATA[📋 本章摘要 在第十八章中,我们使用 捕捉库函数的性能热点,定位到正则表达式库（ 占用 89%）、加密函数和 JSON 解析成为新的瓶颈。通过函数级别的性能分析,将帧率从 30 FPS 提升到 980 FPS。 但当问题进入**内核路径**（调度延迟、软中断拥塞、块 IO 队列、kworker 异常]]></description><category></category></item><item><title><![CDATA[Linux 性能实战 | 第 20 篇：trace-cmd 与 kernelshark 可视化分析 [特殊字符]]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/158045055</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/158045055</guid><author>zhoucoolqi</author><pubDate>Fri, 13 Feb 2026 23:11:57 +0800</pubDate><description><![CDATA[📋 本章摘要 在第十九章中,我们掌握了 ftrace 的核心用法,通过直接操作 接口完成了 kworker 高负载和软中断风暴的排查。但手工操作 ftrace 存在明显的痛点： - **操作繁琐**：需要手动 echo 到多个文件,容易出错 - **数据管理难**：trace 数据无法持久化保存和分]]></description><category></category></item><item><title><![CDATA[Linux 性能实战 | 第 18 篇：ltrace 与库函数性能分析]]></title><link>https://blog.csdn.net/zhoucoolqi/article/details/158013304</link><guid>https://blog.csdn.net/zhoucoolqi/article/details/158013304</guid><author>zhoucoolqi</author><pubDate>Thu, 12 Feb 2026 22:49:17 +0800</pubDate><description><![CDATA[📋 本章摘要 在第十七章中，我们深入探讨了系统调用的性能开销——单次 100-300ns，但频繁调用会累积到整体性能的 50% 以上。通过 strace 诊断，我们发现一个感知算法每秒调用 845,000 次 gettimeofday，导致 load 8.5 但 CPU 使用率仅 15%。通过批量优]]></description><category></category></item></channel></rss>