Linux hung_task故障分析：khungtaskd检测源码
第2章：hung_task Detector源码——khungtaskd是怎么发现阻塞任务的0. 源码基线与本章边界本文以 Linux v6.1 为源码基线，核心文件是 kernel/hung_task.c。对应上游标签提交为 830b3c68c1fb1e9176028d02ef86f3cf76aa2476。 本章只回答一个问题： Linux怎样发现一个不可中断等待任务已经长时间没有调度进展？
CJ's Tech Notes
Linux hung_task故障分析：TASK_UNINTERRUPTIBLE与D状态
第1章：hung_task到底是什么——TASK_UNINTERRUPTIBLE与D状态看到下面的日志，很多人第一反应是“这个线程在CPU上卡死了”： 1INFO: task xxx:1234 blocked for more than 120 seconds. 但hung task通常不是CPU忙循环，而是一个Task长时间睡在不可中断等待路径中。真正要追踪的是：它在等什么、谁应该让条件成立、
Linux GPU/NPU加速器总体架构：完整软件栈
第2章：GPU/NPU完整软件栈——从Application、Runtime、UMD、KMD到Firmware和Hardware上一章解释了CPU、GPU、NPU为何形成不同的执行、调度和内存模型。本章沿一项任务的生命周期继续向下：一个API调用怎样变成设备命令，怎样穿过用户态与内核态，怎样被固件和硬件执行，完成结果又怎样返回应用。 123Application → Framework/
Linux GPU/NPU加速器总体架构：CPU、GPU、NPU的本质区别
第1章：CPU、GPU、NPU到底有什么本质区别——执行模型、调度模型和内存模型后面学习Linux GPU/NPU驱动时，我们会连续遇到context、job、queue、ring、firmware、GPUVM、IOMMU、partition、tile和fence。 如果直接把它们套进CPU调度器的task_struct → runqueue → CPU模型，很容易得到错误结论。例如：把
Linux内存管理子系统源码分析：alloc_pages物理页分配
第8章：alloc_pages()——一个物理页到底是怎么从Linux中分配出来的？上一章建立了Buddy System的静态模型：zone->free_area[]按order和迁移类型保存空闲物理块，大块可以拆分，小块释放后可以合并。 这一章把模型放进真实调用链。我们的目标不是只记住“alloc_pages()会从Buddy取页”，而是回答：内核怎样确定可用Zone、怎样保护水位、为什么
Linux内存管理子系统源码分析：Buddy System整体设计
第7章：Buddy System整体设计——Linux到底怎么管理空闲物理页？前面几章已经把Linux物理内存的基本组织关系建立起来了： 1234567System ↓Node（pg_data_t） ↓Zone（struct zone） ↓Page Frame（struct page） 但知道系统中有哪些物理页，还不等于知道如何分配物理页。内核还必须持续回答下面几个问题： 12345哪些物
订阅博客更新
新文章发布后，通过邮件第一时间告诉你。不群发广告，随时可以取消订阅。