林渡 - 云栖梦泽

[linux内存管理] 第025篇细节拉满，80 张图带你一步一步推演 slab 内存池的设计与实现

本文介绍了 Linux 内核中的 slab 内存池，用于高效地分配和释放小内存块。作者首先回顾了 Linux 内存分配的宏观流程，然后引出 slab 内存池的产生背景和优势。slab 内存池将频繁使用的小内存块池化，避免了频繁的内存分配和释放带来的性能开销。文章详细介绍了 slab 对象池的内存布局，包括对齐、red zone、freepointer 和状态信息等。接着，文章分析了 slab 的总体架构设计，包括 kmem_cache、kmem_cache_cpu 和 kmem_cache_node 等数据结构。最后，文章详细介绍了 slab 内存分配和释放的原理，包括从本地 cpu 缓存、partial 列表、NUMA 节点缓存和伙伴系统中分配和释放内存的场景。

[linux内存管理] 第024篇 slab内存分配器概述

填充操作中的数据结构在内存管理中，填充操作涉及到多个核心数据结构，其中包括： 1. **struct kmem_cache**：代表一种“对象类型”的缓存池。内核启动时或动态创建时，会为常见的内核对象（如 `task_struct`、`fs_struct`、`inode`）各自建立一个 `kmem_cache`，用它来管理该类型对象的分配与回收。 2. **struct array_cache**：本地缓存池，每个CPU一个。当本地缓存池为空时，需要从共享缓存池或者slans_partial/slabs_free中，获取batchcount个对象到本地缓存池。 3. **slab_flags_t flags**：对象分配掩码，用于控制对象的分配行为。 4. **unsigned int num**：一个slab最多可以有多少个对象。 5. **unsigned int gfporder**：一个slab占用多个2的order次方物理页面。 6. **size_t colour**：一个slab分配器有多少个不同的高速缓存行，用于着色。 7. **unsigned int colour_off**：一个着色区长度，和L1高速缓存行大小相同。 8. **void (*ctor)(void *obj)**：构造函数，用于初始化新分配的对象。 9. **const char *name**：slab描述符名字。 10. **struct list_head list**：链表节点，用于把slab描述符添加到全局链表slab_caches中。 11. **int refcount**：本描述符引用计数。 12. **int object_size**：对象实际大小。 13. **int align**：对齐长度。 14. **unsigned long num_active**：当前正被使用（allocated but not freed）的对象总数。 15. **unsigned long num_allocations**：累计分配（kmem_cache_alloc）次数。 16. **unsigned long high_mark**：历史最高的 num_active 值（峰值并发使用量）。 17. **unsigned long grown**：slab “增长”次数：从 partial/slabs_empty 中取空 slab 或新建 slab 的总次数。 18. **unsigned long reaped**：slab “收割”次数：将完全空闲的 slab 返还给伙伴系统的总次数。 19. **unsigned long errors**：运行时遇到的错误次数（如分配失败、参数校验失败等）。 20. **unsigned long max_freeable**：在任意时刻，整 cache 中可一次性返还给伙伴系统的最大页数。 21. **unsigned long node_allocs**：NUMA 环境下，从本节点分配 slab 对象的次数。 22. **unsigned long node_frees**：NUMA 环境下，向本节点返还 slab 对象的次数。 23. **unsigned long node_overflow**：NUMA 本地缓存溢出的次数（本地 node cache 空间不足需借用或返还）。 24. **atomic_t allochit**：分配时直接命中 per-CPU cache 的次数（无需访问 partial/full）。 25. **atomic_t allocmiss**：分配时未命中 per-CPU cache，需要去 partial/full 或新建 slab 的次数。 26. **atomic_t freehit**：释放时直接回填 per-CPU cache 的次数。 27. **atomic_t freemiss**：释放时未能回填 per-CPU cache，需要 flush 回 partial/full 的次数。 28. **int obj_offset**：对象在 slab 内的偏移（bytes），仅在调试模式下有效。 29. **struct kasan_cache kasan_info**：KASAN相关的缓存信息。 30. **unsigned int *random_seq**：用于随机化 freelist 的序列。 31. **unsigned int useroffset**：用户对象偏移量。这些数据结构共同构成了填充操作的核心，它们协同工作，实现了高效、低碎片的内存管理。

任务调度器：从入门到放弃（一）

本文探讨了Linux调度器的运作机制，特别是完全公平调度器（CFS）和实时调度类（RT）的区别，以及控制组（cgroup）如何通过限制资源配额来影响调度结果。文章指出，CFS的优先级代表权重，而非传统意义上的优先级顺序，而cgroup则通过cpu.shares参数来控制资源占比。实验表明，当进程在同一个分组时，其资源占比受到priority权重的影响；当进程在不同分组时，其资源配额受到组的cpu.shares的控制。文章还讨论了cgroup可能带来的问题，如默认资源配额不合理和跨资源group组调用的问题。

[Android稳定性] 第049篇 [问题篇] 软中断霸占CPU导致watchdog无法及时喂狗

**问题现象**：系统出现死机现象。 **问题分析**：通过分析dmesg日志和内核定时器数据，发现是由于watchdog定时器未在规定时间内被“喂狗”导致。进一步分析发现，CPU 3上的定时器时钟落后，导致pet_timer无法在规定时间触发。 **问题根因**：网络驱动中的软中断处理路径占用了较长时间的软中断上下文，并多次禁用底半部，导致定时器软中断无法及时执行。 **解决方案**：建议优化网络驱动中的软中断处理路径，减少底半部的禁用时间，以确保定时器软中断能够及时执行。

[Android稳定性] 第048篇 [原理篇] Android SWT机制介绍

SWT-Android Software Watchdog Timeout 是 Android 系统中的一种监控机制，用于检测 System Server 进程中的核心服务和线程是否卡住，并在必要时自动重启系统。本文介绍了 SWT 的原理、实现方式、常见原因、检查流程以及相关工具的使用。 **SWT 的重要性**： System Server 是 Android 系统的核心进程，为应用程序提供各种服务。如果 System Server 中的核心服务和线程卡住，会导致系统出现各种异常，例如手机卡顿、应用程序无法启动等。SWT 机制可以及时发现并解决这些问题，提高系统稳定性。 **SWT 的实现**： SWT 通过添加 MonitorChecker 和 HandlerChecker 两种 Checker 来监控核心服务和线程。MonitorChecker 检查系统核心服务是否被锁时间过长，HandlerChecker 检查系统核心线程创建的 Looper 管理的消息队列是否阻塞。如果检测到卡顿，SWT 会杀死 System Server 进程并重启系统。 **常见 SWT 原因**：等锁、SurfaceFlinger 卡住、Native 方法执行时间过长、Binder Server 卡住、Zygote fork 进程时卡住、Dump 时间过长等。 **SWT 检查流程**：检查 SWT DB 中的 trace 文件，分析线程状态、call stack 和相关 log，找出卡顿的原因。 **相关工具**： hang_SWT_analysis-v6.1 工具可以自动分析 SWT DB，并生成分析报告。 **性能问题导致的 SWT**：检查 CPU Loading、Low Memory 和 IO 状况，找出性能瓶颈并进行优化。

「知不可忽骤得，托遗响于悲风」

《赤壁赋》是苏轼描绘秋夜泛舟赤壁之下所见的壮丽景象和内心感慨。文章以月夜泛舟、饮酒作乐为背景，引出对历史英雄曹操的回忆，及对人生无常、宇宙永恒的深刻思考。苏轼通过水与月的比喻，表达了对物我关系和人生价值的理解，最终以与客共饮、畅谈人生作结。

[Android稳定性] 第047篇 [问题篇] Unexpected kernel BRK exception at EL1

**问题背景**：多款手机在启用移动热点功能后出现死机现象，涉及BUGO19-6212、BUGO19-6235和BUGO19-6210等多个JIRA问题。 **问题现象**：设备在启用热点后崩溃。经过测试，发现启用热点功能会导致设备死机，与预期不符。 **问题分析**：通过分析堆栈信息和汇编代码，初步判断问题为数组越界。寄存器W26的值超出数组最大值，导致数组越界，进而触发BRK异常。 **wlan模块分析**：在wlan模块中，存在两个for循环，重复复制了同一批非indoor信道，导致pcl_len值翻倍，超出数组最大值。 **解决方案**：删除第二个for循环，避免重复复制信道，从而解决数组越界问题。

【深入内核】linux ftrace详解

本文主要介绍了Ftrace（Function Tracer）的概念、实现原理和使用方法。Ftrace是Linux内核自带的轻量级跟踪框架，用于记录内核内部发生的事件与函数调用，帮助开发者洞察系统最深处的执行路径、时序瓶颈与异常行为。文章详细阐述了Ftrace的实现原理，包括静态插桩和动态插桩两种方式，并介绍了Ftrace的开启方法，包括设置tracer类型、设置tracer参数、使能tracer、进行测试和提取trace结果等步骤。此外，文章还介绍了常见的trace event详解和特别注意点，如能够使用adb和开机过程中死机的情况。

[音乐分享] 莫失莫忘

文章回忆起了一个不酷热的夏天，描述了那时的生活细节，如电视的声响、风扇的转动和西瓜的甜味。作者反思了自己和他人当时的梦想，现已遗忘，只能推测当时未预料到生活的劳累与责任。文章中引用了角色们的豪言壮语，展现了年少时的理想与抱负。

高通平台xbl启动流程补充

本文是对高通Android启动代码流程的进一步分析，聚焦于XBL阶段的启动流程，通过流程图与日志对应的方式详细解析。目前分析尚在进行中，预计2025年8月18日完成全部梳理。

你好,

我是林渡