内存管理是Linux内核最为复杂且最为重要的部分，本文从原理及代码角度对Linux内存管理机制进行分析。

内存的划分

Linux将内存从大到小依次划分为Node（节点）->Zone（内存域）->Page（页）：

• 节点：在大型结算及系统中，内存有不同的簇，依据对处理器距离的不同，访问这些簇有不同的代价。而这些簇就可以成为节点。例：在PC系统中可以理解为实际挂载的物理内存；在嵌入式系统中，有两块内存芯片A和B，分别代表一个节点。
• 内存域：内存域并不是物理存在的概念，是Linux系统对每个内存节点进行管理的单位，每个节点的内存域表示的是对该节点不同地址范围的划分。一般内存域有三种，分别为Normal、DMA和HighMem。
• 页：在每个内存域中，内存被划分为大小固定的块（32位系统一般为4K大小），为内核进行内存分配的基本单位（当然内核内存管理机制其实更为复杂，“基本单位”不代表每次分配内存最小就要分到4K。后边可以看到，当需要获取小于4K大小的内存时，内核有Slab分配器来满足要求）

这是<Linux内核内存管理>系列的第三篇

第一篇为内核内存管理过程知识点的的简单梳理

第二篇介绍了内核的数据结构

前言

以Intel X64 CPU为例，Linux的初始化可大致分为如下几个过程：

1. Loader跳转到内核后的实模式(Real Mode)
2. 32位保护模式跳转到64位长模式
3. 64位长模式下解压内核
4. 解压内核后，建立新的页表映射，并跳转到Arch（平台）相关C代码
5. 执行平台无关初始化代码

本系列是本人对Linux内核内存管理的学习持续总结。

序

内存系统是操作系统最复杂的子系统之一，内存管理穿插着内核的方方面面。做驱动开发有2年多了，之前写过Linux内核内存管理的博客。现在回头看，之前的理解并不到位，也不完整。希望用本系列对Linux内核内存管理的知识做重新梳理，增强自己的理解，也能给对这个复杂功能一头雾水的朋友提供一些思路。

一直以为技术是无国界的，也是不带政治观点的。没想到被NotePad++ 疯狂打脸。
来看看其作者如何表达政治观点的。

至于为什么这么多对华内容，后来了解到这是一个台湾人。
在台湾公司呆了这么多年，从来不会也不可能表达政治观点。同事也都是客客气气的。
但是相信无论是我们或者台湾同事，也都能感受到对方的想法。例如，

距离上次写博客已经有约5个月了。一直没有时间和动力来更新博客。

最近半年，工作异常忙碌，不止一次跟XH表示，这是我工作以来最为忙碌的时光。所幸所做之工作，又是个人认为比较前言且具有挑战的项目。虽然充实，但也持续迷茫着。

外面的世界，贸易战、洪水、新冠肆虐。家里却也非绝对宁静。

去年八月一年来，搬了三次家。上次博客更新时，还在20公里之外的出租房里。现在，也幸得终于可以回到自己的寒舍。房子虽小，也有雨季漏水的问题。却也增添了几分方便，更多了归属感。

今天是20200202，难得的日期对称日，有必要记上一篇。

四川省最后还是刚起，仅仅发了一个不痛不痒的通知说企业可自行安排复工时间，成为遵守国务院命令2月3日准时上班的唯一一个省份。

看着最新的疫情地图，加上查到的1600多万的成都人口，心理慌得不要不要的。料医学博士的省长也没办法抑制得了新病毒的传播，希望成都不要学武汉的各种神操作。幸好公司人性化，允许在家办公。

人类自以为是世界的主宰，实则不然。2020新年伊始，新冠状病毒从武汉开始蔓延。

强大的传染力，加上春节的人口流动速率，病毒感染的人口可能远非官方所报道那么多。

想起2013年的SARS，我高三，生活在小县城也能深切感受到这传染病的威力。
每天早读几个温度计班里传递量体温，诊所里板蓝根早早卖断货。
晚上自习新闻时间打开电视随时关心病情进展，看到又是几个全身防护的医务人员感染甚至病逝的消息。

一直想入手一个智能手表，可惜Apple Watch需要连接苹果手机，遂未能如愿。最近小米终于发布一款智能手表，支持ESIM，使用Wear OS，果断入手。

实际使用发现Bug不少，软件不多。Bug可以等系统更新来解决。不过软件不多是生态链的问题，等生态链慢慢建起来实在太慢。Wear OS是Android的一个分支，理论上应该支持安装安卓应用才对。翻了下小米手表的设置，也是有看到可以做ADB调试，因此理应可以用ADB安装Android应用。

本文介绍和Zephyr线程的数据结构，及相应的API。

数据结构

Zephyr数据结构使用k_thread定义，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

struct k_thread {
	struct _thread_base base;
	struct _callee_saved callee_saved;
	void *init_data;
	void (*fn_abort)(void);

#if defined(CONFIG_THREAD_MONITOR)
	struct __thread_entry entry;
	struct k_thread *next_thread;
#endif
#if defined(CONFIG_THREAD_NAME)
	char name[CONFIG_THREAD_MAX_NAME_LEN];
#endif
#ifdef CONFIG_THREAD_CUSTOM_DATA
	void *custom_data;
#endif
#ifdef CONFIG_THREAD_USERSPACE_LOCAL_DATA
	struct _thread_userspace_local_data *userspace_local_data;
#endif
#ifdef CONFIG_ERRNO
#ifndef CONFIG_USERSPACE
	int errno_var;
#endif
#endif

#if defined(CONFIG_THREAD_STACK_INFO)
	struct _thread_stack_info stack_info;
#endif /* CONFIG_THREAD_STACK_INFO */
#if defined(CONFIG_USERSPACE)
	struct _mem_domain_info mem_domain_info;
	k_thread_stack_t *stack_obj;
#endif /* CONFIG_USERSPACE */
#if defined(CONFIG_USE_SWITCH)
	int swap_retval;
	void *switch_handle;
#endif
	struct k_mem_pool *resource_pool;
	struct _thread_arch arch;
};

前言

一直想写一些RTOS的技术资料，算作对自己之前一些相关技术调研的总结。无奈懒癌发作，一拖再拖。然今日灌上鸡血，笃定主意，从最基本的调度相关内容开始。

简单讲，Zephyr是一个开源实时操作系统。相较Linux，其对系统资源的使用量更小，当然也牺牲了许多复杂且完善的功能（如，系统Debug易用性，线程的堆栈保护）。与此同时，因其是开源社区开发，也多少继承和保留了许多Linux系统的优秀思想和功能（例如，Workqueue、设备树等）。其定位为万物互联时代各种各样的嵌入式设备，目光长远。