wdfk-prog的个人博客

[toc] mm/truncate.c 页面缓存截断(Page Cache Truncation) 文件大小变更的核心内存管理历史与背景这项技术是为了解决什么特定問題而誕生的？这项技术是为了实现一个最基本、最核心的文件系统功能：更改文件的大小，特别是缩减文件（Truncation）。这是一个由POSIX标准规定的基础操作。mm/truncate.c专门负责处理这个操作在内存管理（Memory Management, MM）层面最复杂的部分：确保文件的内存表示（即页面缓存 Page Cache）与文件在磁盘上的新大小保持一致。 它解决了以下核心问题： 内存与磁盘同步：当用户调用truncate()或以O_TRUNC模式打开文件时，不仅需要通知文件系统释放磁盘上的数据块，还必须精确地从内核的页面缓存中移除或修改对应的缓存页。否则，应用程序可能会读到已经被“删除”的陈旧数据，或者脏页（Dirty Page）可能会错误地将已删除的数据写回磁盘。 处理边界条件：文件截断不总是以页面大小（通常是4KB）对齐的。mm/truncate.c必须能精确处理部分被截断的页面，即一个页面中...

[TOC] mm/slub.c SLUB内存分配器(The SLUB Allocator) 现代内核对象缓存的核心历史与背景这项技术是为了解决什么特定问题而诞生的？这项技术以及它所实现的SLUB分配器，是为了解决内核中一个基础且关键的性能问题：如何高效地分配和释放大量小的、固定大小的内存对象。 对抗内部碎片（Internal Fragmentation）：内核需要频繁创建大量的小对象（如inode, dentry, task_struct等），它们的大小通常远小于一个物理内存页（通常是4KB）。如果直接使用页分配器（Buddy System）来为这些小对象分配整个页，会造成巨大的内存浪费。例如，为一个128字节的对象分配一个4096字节的页，97%的内存就被浪费了。 提升分配性能：通用的内存分配器需要处理任意大小的请求，其算法相对复杂。而对于特定类型的对象，我们可以创建一个专用的“对象缓存池”。SLUB分配器就是这种缓存池的实现者。 利用对象构造/析构：很多内核对象在首次使用时需要进行初始化。SLUB框架允许在创建缓存时指定一个“构造函数”（construc...

[TOC] mm/util.cinit_user_buckets: 初始化memdup_user的专用内存桶此代码片段的作用是在内核启动的早期阶段, 创建一个专用的、高性能的内存分配器(一个kmem_buckets实例), 并将其赋给全局指针user_buckets。这个专用的分配器被命名为"memdup_user", 意味着它被内核中的memdup_user()函数和相关函数独占使用, 目的是优化从用户空间复制数据到内核空间时的小块内存分配性能。 工作原理: memdup_user()是一个非常常见的内核函数, 用于安全地从用户空间拷贝一块数据到内核新分配的内存中。这个操作在处理系统调用参数、网络数据包等场景中被频繁调用, 且请求分配的内存大小各不相同。 标准的通用内存分配器kmalloc()虽然功能强大, 但对于这种极其频繁、大小多变的小块内存请求, 其内部的查找和管理开销可能会成为性能瓶颈。 kmem_buckets (内存桶) 则是一种更轻量级、更快的专用分配器, 类似一个内存池(memory pool)。 它内部预先维护了一系列”桶”(b...

[TOC] mm\vmstat.cinit_mm_internals 初始化内存管理（MM）子系统中，那些依赖于其他核心子系统（如workqueue、cpuhp）已经建立的、更深层次的内部组件。它并非内存管理的最早期初始化（如物理页帧分配器的建立），而是一个第二阶段的、功能性的初始化 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364/* * 这是一个静态的、仅在初始化阶段调用的函数，负责初始化内存管理（MM）的内部组件。 */void __init init_mm_internals(void){ /* ret: 用于接收函数返回值，__maybe_unused属性告诉编译器，在某些配置下 * （如非SMP），这个变量可能未被使用，不要因此产生警告。*/ int ret __maybe_unused; /* * 为MM子系统分配一个名为"mm_percpu_...

[toc] fs/anon_inodes.c 匿名inode文件系统(Anonymous Inode Filesystem) 提供内核事件驱动的文件描述符历史与背景这项技术是为了解决什么特定问题而诞生的？这项技术是为了给那些纯粹基于内核内部事件、而没有实体文件系统后端的对象提供一个标准的文件描述符（File Descriptor）接口而诞生的。 在Linux“一切皆文件”的设计哲学下，将各种资源抽象为文件描述符，可以使用read(), write(), poll(), epoll()等一套统一的I/O接口来进行操作。 在anon_inodes出现之前，如果内核想提供一个事件通知机制（例如inotify），它可能需要实现一个迷你的、私有的伪文件系统，只为了创建一个inode和一个file对象返回给用户空间。 这导致了代码的重复和资源的浪费。 anon_inodes.c解决的核心问题是：如何以一种轻量级、标准化、且节约内存的方式，为内核子系统创建并返回一个功能性的文件描述符，而这个文件描述符背后并不对应任何磁盘上的文件或一个完整的伪文件系统。 它的发展经历了哪些重...

[TOC] include/uapi/linux/elf.hElf32_Ehdr (内核中通常用 struct elfhdr): ELF文件头结构体这个结构体是ELF文件格式的“封面”和“目录”，它必须位于任何一个ELF文件的最开头。加载器（如内核）通过读取并解析这个结构体，来了解如何处理文件的其余部分。 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687/* * 这是32位ELF文件头的标准定义. * 内核代码中通常会用 Elf32_Addr, Elf32_Half 等类型来保证在不同架构下的大小是固定的. */typedef struct elf32_hdr { /* * e_ident: 一个16字节的数组, 用于识别文件. 它包含了多个子字段. ...

[TOC] fs/buffer.c 缓冲区管理(Buffer Management) 块设备I/O的核心缓冲层历史与背景这项技术是为了解决什么特定问题而诞生的？fs/buffer.c 及其实现的**缓冲区缓存（Buffer Cache）**是Linux/Unix系统中最古老、最核心的性能优化机制之一。它最初是为了解决一个根本性的问题：物理磁盘I/O操作极其缓慢。 性能瓶颈：相比于CPU和内存的速度，机械硬盘的读写速度要慢上几个数量级。如果每次读写请求都直接访问磁盘，系统性能将严重受限。 提供抽象：内核需要一种方法来为文件系统提供一个统一的、基于块（Block）的设备视图，隐藏底层硬件的复杂性。 缓冲区缓存通过在物理内存（RAM）中缓存磁盘块的内容来解决这个问题。当内核需要读取一个磁盘块时，它首先检查该块是否已经在缓存中。如果在，就直接从内存中读取，避免了昂贵的物理I/O。同样，写操作可以先写入缓存（标记为“脏”），然后由内核在稍后的“最佳”时机批量写回磁盘。 它的发展经历了哪些重要的里程碑或版本迭代？缓冲区缓存的发展史是Lin...

[TOC] fs/dcache.c 目录项缓存(Directory Entry Cache) VFS路径查找加速器历史与背景这项技术是为了解决什么特定问题而诞生的？这项技术以及它所实现的目录项缓存（dcache），是为了解决Linux虚拟文件系统（VFS）中最核心的性能瓶颈之一：路径名到inode的解析过程。 消除磁盘I/O：在一个典型的文件系统中，解析一个路径如/home/user/file.txt需要一系列的磁盘读取操作。首先读取根目录/的内容找到home，然后读取home目录的内容找到user，以此类推，直到最后找到file.txt。每一次目录读取都是一次缓慢的磁盘I/O。如果每次open()或stat()系统调用都执行这个过程，系统性能将无法接受。 提供快速路径查找：dcache在内存中缓存了目录项（dentry）的树状结构，它直接映射了文件系统的目录层次。当内核需要解析一个路径时，它首先在dcache中查找。如果路径的所有组件都在缓存中，整个解析过程就可以在内存中以极高的速度完成，完全无需访问磁盘。 缓存负面结果（Negative Loo...

[toc] fs/drop_caches.c 内核缓存手动回收(Manual Kernel Cache Reclaiming) 提供清空页面、目录和inode缓存的接口历史与背景这项技术是为了解决什么特定问题而诞生的？这项技术是为了给系统管理员、性能测试工程师和内核开发者提供一个手动、强制性地清空内核主要缓存的手段，以解决以下特定问题： 可重复的性能基准测试：在进行磁盘I/O或文件系统性能测试时，上一次运行的结果会“预热”内核缓存（Page Cache）。这导致下一次运行会直接从高速的内存中读取数据，而不是从慢速的磁盘读取，从而使得测试结果不准确，无法反映真实的“冷启动”性能。drop_caches 允许在每次测试前清空缓存，确保测试环境的一致性。 模拟内存压力：开发者需要测试应用程序或内核本身在内存资源紧张时的行为。通过手动清空缓存，可以快速回收大量内存，从而模拟出系统突然面临内存压力的场景。 诊断特定的内存问题：在极少数情况下，内核的slab分配器可能出现严重的内存碎片问题，或者某些驱动程序存在内存泄漏，导致缓存无法被正常回收。drop_caches 可...

[TOC] fs/file.c 文件句柄管理(File Handle Management) 管理已打开文件的核心数据结构历史与背景这项技术是为了解决什么特定问题而诞生的？fs/file.c 及其管理的数据结构是为了解决在多进程操作系统中如何清晰、高效地管理“已打开文件”这一核心概念而诞生的。它解决了以下几个基本问题： 状态的区分：需要区分“磁盘上的文件”和“被打开的文件”。磁盘上的文件有其固有的属性（大小、权限等），而被打开的文件则有其动态的状态，最典型的就是当前的读写位置（offset）。多个进程可以同时打开同一个文件，但每个进程都应该有自己独立的读写位置。 抽象与统一：操作系统需要一个统一的接口来处理所有类型的I/O操作。无论是读写磁盘文件、管道、套接字还是硬件设备，用户空间程序都应该能使用相同的系统调用（read, write, close）。fs/file.c 提供的框架是实现这种统一接口（即VFS - 虚拟文件系统）的关键部分。 资源共享与隔离：需要一种机制来管理文件句柄在进程间的关系。例如，一个进程如何复制一个文件句柄（dup），以及父进程打开...