CPU虚拟化是一种技术，它允许单个物理CPU模拟多个虚拟CPU（VCPU）。这使得多个操作系统（OS）实例能够在同一个物理服务器上并行运行，每个实例都在自己的隔离环境中执行。在虚拟化环境中，操作系统通常运行在被称为虚拟机（VM）的封装环境中。每个VM都像拥有独立的物理硬件一样运行，尽管实际上它们共享着同一台物理机的资源。

1.1-虚拟化技术的关键挑战

1. 特权指令和敏感操作：在没有硬件支持的情况下，CPU虚拟化的主要挑战之一是处理特权指令。这些指令通常只能由物理CPU上的最高权限级别执行，例如，直接访问硬件资源。在虚拟环境中，当虚拟机试图执行这些指令时，必须有一种机制来适当地处理它们，以避免对系统的安全和稳定性造成影响。现代CPU通常存在ring0~ring34个级别，而在linux与windows则只使用ring0与ring3两个级别，通常来说，用户态的代码运行在ring3中，而内核态的代码运行在ring0中，任何直接与硬件交互、管理系统资源的操作都是在ring0下执行的。通常，当CPU在ring3中尝试执行ring0级别操作时，会抛出一个CPU异常，而此时VMM则会捕获这个异常，代替用户态的虚拟机执行该命令。然而在x86平台上不是所有的命令都会抛出异常，有一些敏感指令并不是特权指令，比如在用户态修改中断状态（IF）寄存器，如果在用户态执行该命令，CPU则只会忽略该命令。
   • 特权指令（Privileged Instructions）：
     • 特权指令是那些只能在处理器的最高特权级别（通常是Ring 0，在x86体系结构中被称为内核模式）下运行的指令。
     • 这些指令通常用于执行系统级的操作，如管理硬件设备、改变内存访问权限、控制CPU的状态等。
     • 特权指令的执行通常是受操作系统内核控制的。当用户空间的应用程序需要执行这些操作时，它们会通过系统调用的形式委托给内核执行。
   • 敏感指令（Sensitive Instructions）：
     • 敏感指令是那些对系统的全局状态或资源有影响的指令，这包括特权指令和非特权指令。
     • 敏感指令的范围更广，不仅包括改变或查询处理器模式、硬件配置或其他系统资源的指令，也包括那些可能改变系统的控制流、中断处理或数据流的指令。
2. 资源共享和隔离：虚拟化环境必须确保所有虚拟机可以高效、公平地共享CPU资源，同时保持彼此的隔离，以避免一个虚拟机的操作影响到其他虚拟机。

1.2-虚拟化技术的发展

1. 软件模拟：早期的CPU虚拟化技术，如Bochs和QEMU，使用纯粹的软件模拟来处理特权指令，这种方法的缺点是性能开销较大。另外通常在在A架构上执行B架构虚拟机原理也是模拟。
2. 动态二进制翻译：VMware使用了一种称为动态二进制翻译（DBT）的技术，它在运行时将特权指令转换为不同的指令序列，以在虚拟化环境中正确执行。我们上问题所提到的一种解决x86平台特权指令的方案就是动态翻译。
3. 硬件辅助虚拟化：随后，处理器制造商如Intel和AMD在其CPU中引入了硬件辅助虚拟化技术（例如Intel的VT-x和AMD的AMD-V）。这些技术通过在硬件层面提供对虚拟化的支持，允许虚拟机可以直接执行ring0的代码，这种方案无须对命令进行转译而直接执行命令，故而显著提高了性能和效率。

1.3-虚拟机监控器（VMM）

1. 定义和作用：虚拟机监控器（VMM）是虚拟化技术中的核心组件。它负责管理虚拟机的资源分配、调度和执行。在硬件辅助的虚拟化环境中，VMM通常运行在更高的权限级别，以便控制对硬件的访问和管理虚拟机的执行。
2. VMM的类型：VMM可以是类型一（运行在裸机上）或类型二（运行在宿主操作系统之上）。KVM（Kernel-based Virtual Machine）是一种类型一VMM，而QEMU通常作为类型二VMM使用。

2、硬件辅助虚拟化

2.1-硬件辅助虚拟化的实现

如果想要实现CPU的硬件虚拟化，我们则需要CPU具备一下能力：

1. CPU指令集支持：硬件辅助虚拟化需要CPU支持一组特殊的指令集。这些指令用于管理虚拟机的创建、执行、暂停和销毁。
2. 上下文切换：硬件辅助虚拟化技术允许快速有效地在虚拟机和宿主机环境之间进行上下文切换。这使得虚拟机可以在接近原生性能的情况下运行。

2.2-VMX

Intel开发了一种VT技术以支持虚拟化，为CPU虚拟化增加了一个叫做Virtual-Machine Extensions（VMX）的功能。

VT中的VMX root模式和non-root模式分别用于虚拟机监控器（VMM）和虚拟机（VM）。这种情况下，则可以使虚拟机的内核直接运行在CPU的ring0，也就避免的特权、敏感指令的相关问题，而虚拟机的用户态则继续维持在ring3状态下，保证了系统的安全。

2.2.1-进入虚拟机

运行在ROOT Mode中的VMM第一次将通过VMLaunch命令将CPU状态切换到non-Root Mode，执行进入Guest的VM entry操作。而后续VMM则会通过VMResume命令重新进入到non-Root Mode。通过kvm_arch_vcpu_ioctl_run的ioctl实现用户态的调用。

static fastpath_t vmx_vcpu_run(struct kvm_vcpu *vcpu)
{
	......
	/* 检查是否可以进入虚拟机，如果不需要的话则直接退出 */
	if (unlikely(vmx->emulation_required)) {
		vmx->fail = 0;
		......
		return EXIT_FASTPATH_NONE;
	}

	trace_kvm_entry(vcpu);
	......

	/* 获取HOST中CR3、CR4寄存器状态 */
	cr3 = __get_current_cr3_fast();
	......
	cr4 = cr4_read_shadow();
	......

	/* 执行VMLAUNCH或者VMRESUME，并在完成后退出 */
	vmx_vcpu_enter_exit(vcpu, __vmx_vcpu_run_flags(vmx));

	/* 后边主要是虚拟机退出后，代码会执行一系列清理和状态同步操作 */
	if (kvm_is_using_evmcs()) {
		current_evmcs->hv_clean_fields |=
			HV_VMX_ENLIGHTENED_CLEAN_FIELD_ALL;

		current_evmcs->hv_vp_id = kvm_hv_get_vpindex(vcpu);
	}
	......

	if (unlikely(vmx->fail))
		return EXIT_FASTPATH_NONE;

	if (unlikely((u16)vmx->exit_reason.basic == EXIT_REASON_MCE_DURING_VMENTRY))
		kvm_machine_check();

	/* 完成vcpu生命周期后则会退出虚拟机 */
	trace_kvm_exit(vcpu, KVM_ISA_VMX);
	.....
	if (is_guest_mode(vcpu))
		return EXIT_FASTPATH_NONE;

	return vmx_exit_handlers_fastpath(vcpu);
}

上边的函数最终会调用到arch/x86/kvm/vmx/vmenter.S中的__vmx_vcpu_run的汇编函数进入到虚拟机中，并通过传参flag判断具体是resume还是launch。

/**
 * __vmx_vcpu_run - Run a vCPU via a transition to VMX guest mode
 * @vmx:	struct vcpu_vmx *
 * @regs:	unsigned long * (to guest registers)
 * @flags:	VMX_RUN_VMRESUME:	use VMRESUME instead of VMLAUNCH
 *		VMX_RUN_SAVE_SPEC_CTRL: save guest SPEC_CTRL into vmx->spec_ctrl
 *
 * Returns:
 *	0 on VM-Exit, 1 on VM-Fail
 */

2.2.2-退出虚拟机

而如果guest内核中执行部分特权命令（如I/O访问）时，则会触发CPU陷入的动作，此时则会退出guest VM exit，CPU则从non-Root Mode切换回root Mode，然后VMM则捕获这些特权命令，由其模拟该命令，代替虚拟机内核执行。造成VM Exit的常见情况包括访问I/O端口、处理外部中断等。

退出的实际操作在vmx_vcpu_run中，并且会根据不同的退出原因执行对应的逻辑。

static fastpath_t vmx_exit_handlers_fastpath(struct kvm_vcpu *vcpu)
{
	switch (to_vmx(vcpu)->exit_reason.basic) {
	case EXIT_REASON_MSR_WRITE:
		return handle_fastpath_set_msr_irqoff(vcpu);
	case EXIT_REASON_PREEMPTION_TIMER:
		return handle_fastpath_preemption_timer(vcpu);
	default:
		return EXIT_FASTPATH_NONE;
	}
}

其中退出的原因分析如下

• EXIT_REASON_MSR_WRITE：
  • 当虚拟机尝试写入一个模型特定寄存器（MSR）时，会触发此类VM Exit。
  • handle_fastpath_set_msr_irqoff函数处理这种类型的VM Exit，它会快速响应MSR写操作。这通常涉及到更新虚拟机的MSR值，而不需要复杂的模拟或状态更新。这种处理通常比完全模拟MSR写操作更高效。
• EXIT_REASON_PREEMPTION_TIMER：
  • 当VMX预处理计时器到期时，会触发这种VM Exit。
  • handle_fastpath_preemption_timer函数处理这种类型的VM Exit，它通常涉及到更新虚拟机的计时器状态或调度信息。这可以用于确保虚拟机不会占用过多的宿主CPU时间，从而允许宿主操作系统更公平地分配处理器资源给其他任务。

而KVM模块中的handle_exit以及__vmx_handle_exit只是用来处理已经退出的虚拟机后续状态，而不是直接执行退出的实际逻辑。通过上述逻辑大概也可以看到，虚拟机退出时主要是被动退出，而不是类似于进入时的主动调用。

static int vmx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t exit_fastpath)
{
	int ret = __vmx_handle_exit(vcpu, exit_fastpath);

	......
	return ret;
}

2.2.3-vcpu上下文

VMCS（Virtual Machine Control Structure）：在VT-x中，VMCS是用来保存虚拟机的状态和控制虚拟机执行的数据结构。每个VCPU都有一个对应的VMCS，它包含了关于VCPU的执行状态、控制字段和其他管理信息。

在v6.6中被定义在了arch/x86/kvm/vmx/vmcs.h，主要包含以下几个结构体

struct vmcs_hdr {
	u32 revision_id:31;   // VMCS数据结构的版本号，用于确保VMCS的兼容性
	u32 shadow_vmcs:1;    // 指示是否使用影子VMCS，用于嵌套虚拟化
};

struct vmcs {
	struct vmcs_hdr hdr;  // 包含VMCS头部信息
	u32 abort;            // 如果VMCS操作失败，此字段被设置
	char data[];          // 动态大小的数组，用于存储VMCS数据
};
DECLARE_PER_CPU(struct vmcs *, current_vmcs); // 每个CPU核心的当前VMCS指针

struct vmcs_host_state {
	unsigned long cr3;   // 宿主机的CR3寄存器值，可能与实际的CR3不同
	unsigned long cr4;   // 宿主机的CR4寄存器值，可能与实际的CR4不同
	unsigned long gs_base; // GS段的基址
	unsigned long fs_base; // FS段的基址
	unsigned long rsp;     // 宿主机的栈指针

	u16           fs_sel, gs_sel, ldt_sel; // FS、GS和LDT的选择子
#ifdef CONFIG_X86_64
	u16           ds_sel, es_sel;         // DS和ES的选择子（仅在x86_64体系结构中）
#endif
};

struct vmcs_controls_shadow {
	u32 vm_entry;        // VM Entry相关的控制字段
	u32 vm_exit;         // VM Exit相关的控制字段
	u32 pin;             // 处理器相关的控制字段
	u32 exec;            // 执行控制字段
	u32 secondary_exec;  // 辅助执行控制字段
	u64 tertiary_exec;   // 第三级执行控制字段（如果可用）
};

struct loaded_vmcs {
	struct vmcs *vmcs;        // 指向当前VMCS的指针
	struct vmcs *shadow_vmcs; // 指向影子VMCS的指针（用于嵌套虚拟化）
	int cpu;                  // VMCS所在的CPU编号，如果未加载则为-1
	bool launched;            // 指示VMCS是否已经被VMLAUNCH指令启动
	bool nmi_known_unmasked;  // 指示NMI（非屏蔽中断）是否已知为未屏蔽
	bool hv_timer_soft_disabled; // 指示是否软禁用了虚拟化定时器
	int soft_vnmi_blocked;    // 支持没有vnmi的CPU，记录vnmi被软屏蔽的状态
	ktime_t entry_time;       // 记录进入虚拟机的时间点
	s64 vnmi_blocked_time;    // vnmi被屏蔽的持续时间
	unsigned long *msr_bitmap; // 指向MSR位图的指针
	struct list_head loaded_vmcss_on_cpu_link; // 链接到同一CPU上的其他VMCS
	struct vmcs_host_state host_state; // 宿主机状态的缓存
	struct vmcs_controls_shadow controls_shadow; // 控制字段的阴影副本
};

2.2.4-总结

具备VMX的CPU相比如其他CPU具有如下特点：

1. 虚拟机的系统调用是直接陷入的guest内核空间，而不是host的内核空间。
2. 外部中断的实际处理仍有HOST内核完成，但是接收中断则是guest实现，guest完成接收后要退出虚拟机交由host内核进一步处理资源。（IO透传技术则会避免退出虚拟的问题）
3. 只有敏感指令才会从guest陷入host，由VMM代替虚拟机完成具体操作。

3、QEMU、KVM、libvirt、virsh之间的关系

3.1-具体介绍

1. qemu

QEMU是一种开源的机器模拟器和虚拟化器。它可以模拟多种硬件，使得它可以在不同架构上运行各种操作系统。在不使用KVM的情况下，QEMU使用软件模拟来执行虚拟机中的指令。

• QEMU（Quick Emulator） 是一个开源的硬件虚拟化产品，它可以模拟各种硬件平台，允许用户在一个主机上运行多个操作系统。
• QEMU本身可以提供软件模拟的虚拟化，但当结合KVM使用时，可以利用硬件辅助，大大提高虚拟化的性能。

2. KVM

KVM是Linux内核的一部分，它利用了硬件辅助虚拟化技术，特别是Intel的VT-x或AMD的AMD-V。当与QEMU结合使用时，KVM能够提供接近原生的性能，因为它允许直接在硬件上运行虚拟机的代码。

• KVM（Kernel-based Virtual Machine） 是一个Linux内核模块，它将Linux转变为一个类型1（裸机）的虚拟机监控器（Hypervisor）。
• KVM依赖于硬件虚拟化特性（如Intel VT或AMD-V），提供高效的虚拟化解决方案。
• KVM允许QEMU利用硬件加速功能，提高其虚拟化性能。

3. libvirt

• libvirt 是一个开源的虚拟化API库，为管理虚拟化平台提供了一个通用和稳定的层。
• 它支持多种虚拟化技术，包括KVM、QEMU、Xen等。
• libvirt提供了一套统一的API来管理虚拟机和其他虚拟化资源，使得管理员可以透过统一的接口进行虚拟机的部署、监控和管理。

4. virsh

• virsh（Virtualization Shell） 是一个基于命令行的工具，用于使用libvirt库来管理虚拟机和其他虚拟化资源。
• virsh允许用户执行各种虚拟化相关的任务，如创建、修改、启动和停止虚拟机。
• 它是一个与libvirt交互的前端工具，为用户提供了一个简单但功能强大的方式来管理虚拟化环境。

3.2 总结

KVM是集成在linux kernel中的一部分，他提供出了一些用户态的接口/dev/kvm来供用户态的进程管理虚拟机，但是其本身是不具备虚拟机模拟的能力的，因此内核基于qemu开发出了一套适配kvm的工具，也就是kvm-qemu，通过标准的文件操作例如open、write、ioctl等调用内核的KVM接口。所以可以看做qemu是是虚拟机的用户态工具，而qemu在CPU与内存虚拟化部分依赖KVM基于CPU平台硬件虚拟化所暴露出来的接口。

另外KVM只提供了内存和CPU的虚拟化能力，所以为了实现一个可用的计算机系统，还需要IO外设，例如网卡和硬盘，这部分能力则需要由qemu提供。

而libvirt则是用来统一各个虚拟化接口的库，virsh则是libvirt的命令行工具，即我们在命令行中执行的下令命令

virsh list 
virsh create xxx

4、总结

虚拟化技术，在特别是CPU虚拟化领域，已经成为现代计算架构的一个基石。从早期的软件模拟到现在的硬件辅助虚拟化，它不断进化，提高了效率和安全性。通过像QEMU和KVM这样的工具，我们可以轻松地在单个物理机器上运行多个操作系统实例，极大地提高了资源的利用率和灵活性。

随着技术的不断发展，我们可以期待虚拟化技术在性能、安全性和易用性方面的进一步提升，为未来的计算模式铺平道路。

[TOC]

1、配置安装

腾讯云指引文档：手动搭建 Ghost 博客

2、post配置评论区

官方指引：Disqus + Ghost

1. 首先注册Disqus账号：Disqus sign up

2. 然后选择comment on my site

3. 配置shortname，把shortname配置到/var/www/ghost/content/themes/[CurrentTheme]/post.hbs中的EXAPLE字段

        <section class="article-comments gh-canvas">
            <div id="disqus_thread"></div>
            <script>
                var disqus_config = function () {
                    this.page.url = "{{url absolute="true"}}";
                    this.page.identifier = "ghost-{{comment_id}}"
                };
                (function() {
                var d = document, s = d.createElement('script');
                s.src = 'https://EXAPLE.disqus.com/embed.js';
                s.setAttribute('data-timestamp', +new Date());
                (d.head || d.body).appendChild(s);
                })();
            </script>
        </section>

4. 重启ghost

ghost restart

3、配置post排序

1. 构建collection：

   官方指引：Building content collections

2. 修改排序：

   官方指引：Define a custom route

4、升级ghost版本

官方文档：Supported Node versions

1. 切换到创建ghost的用户

su user

2. 进入到ghost目录，执行升级

cd /var/www/ghost
ghost update

3. 但是注意，由于ghost需要node.js支持，所有升级ghost的同时也可能需要升级node，升级过程中注意参考官方文档。

描述进程状态的基础数据结构名称是task_struct，在内核的include/linux/sched.h中定义。

随着内核的发展，这个结构体里的内容越来越多，6.6的版本上，现在直接800+行，下边截取一些关键的片段。

struct task_struct {
#ifdef CONFIG_THREAD_INFO_IN_TASK
	/*
	 * For reasons of header soup (see current_thread_info()), this
	 * must be the first element of task_struct.
	 */
	struct thread_info		thread_info;
#endif
	unsigned int			__state; // 进程的几种状态，running、dead、zombie、d状态等
......
	int				prio; // 进程优先级
	int				static_prio;
	int				normal_prio;
	unsigned int			rt_priority;
	struct sched_entity		se; // 进程的调度数据结构
	struct sched_rt_entity		rt;
	struct sched_dl_entity		dl;
	const struct sched_class	*sched_class;
#ifdef CONFIG_CGROUP_SCHED
	struct task_group		*sched_task_group; // 进程调度的cgroup组
#endif
......
	unsigned int			policy;
	int				nr_cpus_allowed; // 允许调度的CPU
	const cpumask_t			*cpus_ptr; // 进程所在的CPU mask数据结构
	cpumask_t			*user_cpus_ptr;
	cpumask_t			cpus_mask;
	void				*migration_pending;
	struct sched_info		sched_info; // 有关任务调度的统计信息
	struct list_head		tasks;
	struct mm_struct		*mm; // 进程的内存相关信息
	struct mm_struct		*active_mm;
	...... // 后边都是表示内存的数据结构
	struct restart_block		restart_block;
	pid_t				pid; // 表示进程基础的pid和tgid（进程组号）
	pid_t				tgid;
	/* Real parent process: */
	struct task_struct __rcu	*real_parent; // 一个双向链表原来管理task struct（创建该进程的父进程）
	/* Recipient of SIGCHLD, wait4() reports: */
	struct task_struct __rcu	*parent; // 接收到 SIGCHLD 信号的进程
	/*
	 * Children/sibling form the list of natural children:
	 */
	struct list_head		children; // 树状结构来管理各个task strcut
	struct list_head		sibling;
	struct task_struct		*group_leader;
	/* PID/PID hash table linkage. */
	struct pid			*thread_pid; // 各个task struct的hash表
	struct hlist_node		pid_links[PIDTYPE_MAX];
	struct list_head		thread_group;
	struct list_head		thread_node;
	/*
	 * executable name, excluding path.
	 *
	 * - normally initialized setup_new_exec()
	 * - access it with [gs]et_task_comm()
	 * - lock it with task_lock()
	 */
	char				comm[TASK_COMM_LEN]; //进程名，最大16个字符
	struct nameidata		*nameidata;
	/* Filesystem information: */
	struct fs_struct		*fs; // 进程的文件系统相关资源
	/* Open file information: */
	struct files_struct		*files; // 进程的文件相关资源
	/* Signal handlers: */
	struct signal_struct		*signal; // 进程调度信息
	/* Protection against (de-)allocation: mm, files, fs, tty, keyrings, mems_allowed, mempolicy: */
	spinlock_t			alloc_lock; // 该进程的旋锁
	struct wake_q_node		wake_q; // 用来唤醒进程调度，即调度的时候体现出来的wakeup事件
	/* CPU-specific state of this task: */
	struct thread_struct		thread;
	/*
	 * WARNING: on x86, 'thread_struct' contains a variable-sized
	 * structure.  It *MUST* be at the end of 'task_struct'.
	 *
	 * Do not put anything below here!
	 */
};

从task_struct中可以不难看到，内核中管理各个进程的方式一共有三种：

• 双向链表
• 树

可以比较方便的用来查看进程之间的父子关系

• 哈希

其实主要是通过一个表示进程pid的hash来管理，方便通过pid号直接找到对应进程的task_struct信息。

通过kernel/pid.c里的相关函数进行管理，比如find_pid_ns或者find_vpid，而网上常说的其实早已经被删除了。

#define pid_hashfn(x)    hash_long((unsigned long)x, pidhash_shift)  

（这里吐槽一下，中文互联网真的是喜欢传播旧的东西。一个v2.6的代码，被无数人粘贴复制，这篇2023年的文章，还在用这个宏https://developer.aliyun.com/article/1204882。）

但是很奇怪的是，下边这个commit又说删除了pidhash的相关数据结构，这里可能还有后半再看下，是不是将pidhash的数据结构放在了 idr（ID Radix 树）中，而且确实从代码中发现，只剩下idr init，而没有了hash init。

From e8cfbc245e24887e3c30235f71e9e9405e0cfc39 Mon Sep 17 00:00:00 2001
From: Gargi Sharma <gs051095@gmail.com>
Date: Fri, 17 Nov 2017 15:30:34 -0800
Subject: [PATCH] pid: remove pidhash

pidhash is no longer required as all the information can be looked up
from idr tree.  nr_hashed represented the number of pids that had been
hashed.  Since, nr_hashed and PIDNS_HASH_ADDING are no longer relevant,
it has been renamed to pid_allocated and PIDNS_ADDING respectively.

2、进程状态

Linux的进程中主要有5种状态:

• R (TASK_RUNNING)，就绪态。
• S (TASK_INTERRUPTIBLE)，可中断的睡眠状态
• D (TASK_UNINTERRUPTIBLE)，不可中断的睡眠状态。
• Z (TASK_DEAD - EXIT_ZOMBIE)，僵尸态。
• T (TASK_STOPPED or TASK_TRACED)，暂停状态或跟踪状态。

#define TASK_RUNNING			0x00000000
#define TASK_INTERRUPTIBLE		0x00000001
#define TASK_UNINTERRUPTIBLE		0x00000002
#define __TASK_STOPPED			0x00000004
#define __TASK_TRACED			0x00000008
/* Used in tsk->exit_state: */
#define EXIT_DEAD			0x00000010
#define EXIT_ZOMBIE			0x00000020

2.1 就绪态

进程会在以下几种情况下切换到TASK_RUNNING状态（不是全部，举例说明）：

1. 进程刚被创建时。

   当一个新进程被创建时，它的初始状态是TASK_RUNNING。

   在早期的内核中，进程是通过_do_fork来进行创建进程，在v5.10中的commit将其更名为kernel_clone

   commit cad6967ac10843a70842cd39c7b53412901dd21f
   Author: Christian Brauner <brauner@kernel.org>
   Date:   Wed Aug 19 12:46:45 2020 +0200
   
       fork: introduce kernel_clone()
   

   在这个函数中

   pid_t kernel_clone(struct kernel_clone_args *args)
   {
     ......
   	wake_up_new_task(p);
     ......
   }
   
   void wake_up_new_task(struct task_struct *p)
   {
   	struct rq_flags rf;
   	struct rq *rq;
   
   	raw_spin_lock_irqsave(&p->pi_lock, rf.flags);
   	WRITE_ONCE(p->__state, TASK_RUNNING);
     ......
   }
   

2. 进程从等待状态（TASK_INTERRUPTIBLE或TASK_UNINTERRUPTIBLE）唤醒。

   当进程等待某个事件（如I/O完成、信号量可用等）时，它会进入等待状态。当事件发生时，进程会被唤醒并切换到TASK_RUNNING状态。

   比较常见的是通过__wake_up_common来唤醒进程，并继续执行相关的调度。

    static int __wake_up_common(struct wait_queue_head *wq_head, unsigned int mode,
   			int nr_exclusive, int wake_flags, void *key,
   			wait_queue_entry_t *bookmark)
   {
   	wait_queue_entry_t *curr, *next;
   	......
   		ret = curr->func(curr, mode, wake_flags, key);
     ......
   }
   

   通常使用include/linux/wait.h中定义的.func = default_wake_function,来实现wake操作。

   int try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
   {
   		......
   		trace_sched_waking(p);
   		ttwu_do_wakeup(p);
       ......
   }
   
   static inline void ttwu_do_wakeup(struct task_struct *p)
   {
   	WRITE_ONCE(p->__state, TASK_RUNNING);
   	trace_sched_wakeup(p);
   }
   

3. 进程从暂停状态（TASK_STOPPED或TASK_TRACED）恢复。

   当进程因为接收到SIGSTOP、SIGTSTP、SIGTTIN或SIGTTOU信号而暂停时，它会进入TASK_STOPPED或TASK_TRACED状态。当进程接收到SIGCONT信号时，它会恢复运行并切换到TASK_RUNNING状态。

   static bool prepare_signal(int sig, struct task_struct *p, bool force)
   {
   	......
   	} else if (sig == SIGCONT) {
   		unsigned int why;
   		/*
   		 * Remove all stop signals from all queues, wake all threads.
   		 */
   		siginitset(&flush, SIG_KERNEL_STOP_MASK);
   		flush_sigqueue_mask(&flush, &signal->shared_pending);
   		for_each_thread(p, t) {
   				......
   				wake_up_state(t, __TASK_STOPPED);
   				......
   }
   

   可以看到，这里就是从一个stop状态的进程切换回运行态。

4. 执行正常调度的时候

   这里是指，在调用schedule()对queue里的task进行调度时，会自然将进程切换为running态。

   首先是在__schedule中，判断当前的进程（将要被切换走的）是不是有未处理的信号，如果有，则直接将这个切成runnnig

   		if (signal_pending_state(prev_state, prev)) {
   			WRITE_ONCE(prev->__state, TASK_RUNNING);
   		} 
   

   接下来，则是通过cfs，开始选择下一个执行的task，并在context_switch里更换为running状态。

   next = pick_next_task(rq, prev, &rf);
   ......
   rq = context_switch(rq, prev, next, &rf);
   

   （gpt说的，根本没找到，这里感觉根本就不会，cfs在挑选的时候实在rq中选一个task，而rq中的task已经是running的了，gpt在胡扯）

2.2-TASK_INTERRUPTIBLE

常见于进程完成当前调度任务后主动进入休眠，也可以用与等待部分IO资源。

例如下列这种用法，vcpu线程在执行完当前周期后主动会陷入sleep，并让出CPU，等待下一次调度唤醒。

bool kvm_vcpu_block(struct kvm_vcpu *vcpu)
{
	struct rcuwait *wait = kvm_arch_vcpu_get_wait(vcpu);
	bool waited = false;

	vcpu->stat.generic.blocking = 1;

	preempt_disable();
	kvm_arch_vcpu_blocking(vcpu);
	prepare_to_rcuwait(wait);
	preempt_enable();

	for (;;) {
		set_current_state(TASK_INTERRUPTIBLE); // 设置自身状态为TASK_INTERRUPTIBLE

		if (kvm_vcpu_check_block(vcpu) < 0)
			break;

		waited = true;
		schedule(); // 主动让出CPU，正式sleep
	}

	preempt_disable();
	finish_rcuwait(wait);
	kvm_arch_vcpu_unblocking(vcpu);
	preempt_enable();

	vcpu->stat.generic.blocking = 0;

	return waited;
}

可被signal唤醒。

2.3-TASK_UNINTERRUPTIBLE

主要是在等待资源，例如关键的IO资源，例如下列这段md_bitmap_startwrite部分函数

if (unlikely(COUNTER(*bmc) == COUNTER_MAX)) {
    DEFINE_WAIT(__wait);
    /* note that it is safe to do the prepare_to_wait
     * after the test as long as we do it before dropping
     * the spinlock.
     */
    prepare_to_wait(&bitmap->overflow_wait, &__wait,
            TASK_UNINTERRUPTIBLE);
    spin_unlock_irq(&bitmap->counts.lock);
    schedule();
    finish_wait(&bitmap->overflow_wait, &__wait);
    continue;
}

有时在进程进入关键流程后，也会将其设置为TASK_UNINTERRUPTIBLE，比如在kthread_stop中等待进程完成并返回时，会将自身设置成TASK_UNINTERRUPTIBLE，避免被再次其他信号意外唤醒。

void __sched wait_for_completion(struct completion *x)
{
	wait_for_common(x, MAX_SCHEDULE_TIMEOUT, TASK_UNINTERRUPTIBLE);
}

不可被signal唤醒，只能靠自身调度唤醒。

2.4-EXIT_ZOMBIE&EXIT_DEAD

当一个子进程结束执行（即完成它的任务或被终止），但其父进程尚未通过调用 wait() 系列函数来读取子进程的退出状态时，子进程会进入 EXIT_ZOMBIE 状态。在这种状态下，子进程的大部分资源都被释放了，但它在进程表中保留了一个条目，其中包含了退出状态、进程ID等信息，以便父进程稍后查询。在do_exit()中通知父进程的函数值会设置进程的僵尸态。

static void exit_notify(struct task_struct *tsk, int group_dead)
{
	bool autoreap;
	struct task_struct *p, *n;
	LIST_HEAD(dead);

	......

	tsk->exit_state = EXIT_ZOMBIE;
  ......
}

当父进程通过 wait() 系列函数读取了僵尸子进程的退出状态后，子进程的状态会变为 EXIT_DEAD。在这个状态下，子进程的进程表条目和剩余资源将被彻底释放和回收。在wait_task_zombie中会设置相关状态。

/*
 * Handle sys_wait4 work for one task in state EXIT_ZOMBIE.  We hold
 * read_lock(&tasklist_lock) on entry.  If we return zero, we still hold
 * the lock and this task is uninteresting.  If we return nonzero, we have
 * released the lock and the system call should return.
 */
static int wait_task_zombie(struct wait_opts *wo, struct task_struct *p)
{
  ......
	if (state == EXIT_TRACE) {
		write_lock_irq(&tasklist_lock);
		/* We dropped tasklist, ptracer could die and untrace */
		ptrace_unlink(p);

		/* If parent wants a zombie, don't release it now */
		state = EXIT_ZOMBIE;
		if (do_notify_parent(p, p->exit_signal))
			state = EXIT_DEAD;
		p->exit_state = state;
		write_unlock_irq(&tasklist_lock);
	}
	if (state == EXIT_DEAD)
		release_task(p);
  ......
}

2.5-__TASK_TRACED&__TASK_TRACED

__TASK_TRACED进程被追踪之后的状态。

static inline void ptrace_signal_wake_up(struct task_struct *t, bool resume)
{
	unsigned int state = 0;
	if (resume) {
		t->jobctl &= ~JOBCTL_TRACED;
		state = __TASK_TRACED;
	}
	signal_wake_up_state(t, state);
}

__TASK_STOPPED 状态表示进程已经停止执行，通常是因为收到了如 SIGSTOP、SIGTSTP、SIGTTIN 或 SIGTTOU 等信号。

例如do_signal_stop中会设置进程为set_special_state(TASK_STOPPED);

3、进程状态的转换

主要分析进程创建fork，线程、进程关系、copy_on_write。

1、复制进程

fork是通过复制父进程的方式来创建一个新的进程，内核中相关键函数和流程主要是被定义在了kernel/fork.c之中，通过fork.c里我们可以看到，有几个常用的sys_call:

• fork
• vfork

#ifdef __ARCH_WANT_SYS_FORK
SYSCALL_DEFINE0(fork)
{
#ifdef CONFIG_MMU
	struct kernel_clone_args args = {
		.exit_signal = SIGCHLD,
	};

	return kernel_clone(&args);
#else
	/* can not support in nommu mode */
	return -EINVAL;
#endif
}
#endif

#ifdef __ARCH_WANT_SYS_VFORK
SYSCALL_DEFINE0(vfork)
{
	struct kernel_clone_args args = {
		.flags		= CLONE_VFORK | CLONE_VM,
		.exit_signal	= SIGCHLD,
	};

	return kernel_clone(&args);
}
#endif

接下里的内容我们就会分析一下这些调用流程。

1.1-fork

fork的作用是：完全复制父进程，fork 创建的子进程是父进程的一个完整副本，包括父进程的数据段、堆和栈的副本。

通过fork的定义可以看到，在调用kernel_clone之前，填充了kernel_clone_args结构体。

	struct kernel_clone_args args = {
		.exit_signal = SIGCHLD,
	};

这里的exit_signal表示当子进程退出时，用来通知父进程的信号，比如 SIGCHLD。

而所谓的父进程也就是创建他的进程，当父进程接收到了这个信号后，就会对其进行后续的相关处理，这里具体的收尸操作我们后续一起分析。

另外为了节省操作，fork在创建进程的时候，暂时不会在创建进程的时候就为子进程准备好具体的内存空间，只在具体修改时才会分配实际的内存空间，这就是copy-on-write也就是写时复制的操作。

1.2-vfork

而在vfork中，传递的参数有点区别。

	struct kernel_clone_args args = {
		.flags		= CLONE_VFORK | CLONE_VM,
		.exit_signal	= SIGCHLD,
	};

可以看到，这里在传递flag中增加了两个标记，而其作用主要是在后续流程中区分vfork操作，vfork创建的子进程与父进程共享相同的内存空间。

但是貌似vfork的使用比较少，尤其是在fork存在copy-on-write的背景下。

1.3-kernel_clone

不论是fork还是vfork，最终都会调用到kernel_clone。

kernel_clone在v5.10里被引入到内核之中，在旧的版本中是do_fork。

commit cad6967ac10843a70842cd39c7b53412901dd21f
Author: Christian Brauner <brauner@kernel.org>
Date:   Wed Aug 19 12:46:45 2020 +0200

    fork: introduce kernel_clone()

接下来我们分析一下kerne_clone的具体内容，核心的操作是调用copy_process复制进程。

pid_t kernel_clone(struct kernel_clone_args *args)
{
	......
	p = copy_process(NULL, trace, NUMA_NO_NODE, args); // 主要进行进程复制
	add_latent_entropy(); // 创建新进程时增加一些随机性，从而提高系统的熵
	......

	pid = get_task_pid(p, PIDTYPE_PID); // 分配一个pid给当前进程
	nr = pid_vnr(pid);
	......
	if (clone_flags & CLONE_VFORK) { // 分配vfork工作
		p->vfork_done = &vfork;
		init_completion(&vfork);
		get_task_struct(p);
	}

	if (IS_ENABLED(CONFIG_LRU_GEN) && !(clone_flags & CLONE_VM)) { // 处理一下进程lru的相关数据
		/* lock the task to synchronize with memcg migration */
		task_lock(p);
		lru_gen_add_mm(p->mm);
		task_unlock(p);
	}

	wake_up_new_task(p); // 唤醒当前进程
	......
	put_pid(pid);
	return nr;
}

copy_process的流程很长，就不一一分析了，其中主要流程如下：

1. 首先，函数会检查clone_flags中的一些标志，以确定新进程的一些属性。例如，如果设置了CLONE_NEWNS和CLONE_FS标志，新进程将在新的命名空间中，并且与父进程共享文件系统。
2. 然后，函数会创建一个新的task_struct结构体实例，这个结构体用于表示新的进程。新进程的所有信息都将存储在这个结构体中。
3. 接着，函数会复制父进程的各种属性到新进程中。这包括进程的凭据（如用户ID和组ID）、资源限制、文件描述符表、文件系统上下文、信号处理函数、内存管理结构、命名空间等。
4. 然后，函数会对新进程进行一些初始化操作，例如设置进程的状态、初始化进程的计时器、设置进程的父进程和子进程列表等。
5. 在所有这些操作完成之后，新进程将被添加到系统的进程列表中，这使得它可以被系统的调度器看到并且开始运行。
6. 最后，如果所有操作都成功完成，copy_process函数将返回一个指向新进程的task_struct结构体的指针。如果在创建新进程的过程中发生错误，函数将返回一个错误指针。

在kernel_clone其中vfork的一个区别操作是填充vfork_done结构体，用来标识vfork操作完成。

	if (clone_flags & CLONE_VFORK) { // 分配vfork工作
		p->vfork_done = &vfork;
		init_completion(&vfork);
		get_task_struct(p);
	}

如果包含，那么就设置新进程的vfork_done字段为&vfork，这个字段用于指示vfork操作何时完成。然后，调用init_completion函数初始化vfork完成变量，这个函数将完成变量的状态设置为未完成。

问题：fork复制了新的内存空间，那有哪些具体的内存或者资源被复制了。

例如在copy_mm中，如果是vfork，则把当前的mm结构体指向父进程的。

	if (clone_flags & CLONE_VM) {
		mmget(oldmm);
		mm = oldmm;
	} else {
		mm = dup_mm(tsk, current->mm);
		if (!mm)
			return -ENOMEM;
	}

另外，copy_namespaces如果是vfork的话也不会执行相关的逻辑，而是直接返回。

1.4-clone3

另外还有一个下列常用的sys_call，clone3可以看作是更精细的fork操作。允许细粒度控制子进程的属性，包括内存共享、信号处理等。因此，更适合于需要复杂进程管理的现代应用，如容器和虚拟化。

SYSCALL_DEFINE2(clone3, struct clone_args __user *, uargs, size_t, size)
{
	int err;

	struct kernel_clone_args kargs;
	pid_t set_tid[MAX_PID_NS_LEVEL];

	kargs.set_tid = set_tid;

	err = copy_clone_args_from_user(&kargs, uargs, size); // 在系统调用时，我们可以指定传参clone_flags
	if (err)
		return err;

	if (!clone3_args_valid(&kargs))
		return -EINVAL;

	return kernel_clone(&kargs); // 按照用户态定义的clone_flags来执行进程复制操作。
}

2、创建一个全新进程

当在用户态执行./bin的时候就会调用到execve的系统调用进程进程的创建。

内核中通过fs/exec.c中的函数创建一个全新的进程，而不是通过复制的方式。 execve()系统调用用于在新创建的进程中加载并执行一个新程序，替换当前进程的地址空间。

SYSCALL_DEFINE3(execve,
		const char __user *, filename,
		const char __user *const __user *, argv,
		const char __user *const __user *, envp)
{
	return do_execve(getname(filename), argv, envp);
}

经过一系列的调用，最终会通过bprm_execve来创建新的进程。

/*
 * sys_execve() executes a new program.
 */
static int bprm_execve(struct linux_binprm *bprm,
		       int fd, struct filename *filename, int flags)
{
	struct file *file;
	int retval;

	retval = prepare_bprm_creds(bprm); // 准备新进程的凭证（如UID、GID等）
	if (retval)
		return retval;

	/*
	 * Check for unsafe execution states before exec_binprm(), which
	 * will call back into begin_new_exec(), into bprm_creds_from_file(),
	 * where setuid-ness is evaluated.
	 */
	check_unsafe_exec(bprm);
	current->in_execve = 1; // 标记当前进程正在执行execve
	sched_mm_cid_before_execve(current);

	file = do_open_execat(fd, filename, flags); // open当前的文件
	......
	sched_exec();
	......
	/* Set the unchanging part of bprm->cred */
	retval = security_bprm_creds_for_exec(bprm); // 检查要执行进程的安全性，例如selinux
	......
	retval = exec_binprm(bprm); // 执行二进制，创建进程
    ......
	/* 执行成功后，要重置一下进程的统计信息 */
	current->fs->in_exec = 0;
	current->in_execve = 0;
	rseq_execve(current);
	user_events_execve(current);
	acct_update_integrals(current);
	task_numa_free(current, false);
	return retval;
	......
}

而exec_binprm则中会调用search_binary_handler来搜索当前二进制的执行方法，例如如果是elf二进制则调用load_elf_binary，而在其中则会设置二进制的入口函数e_entry = elf_ex->e_entry + load_bias;，并且也会做好内存空间的准备

static int load_elf_binary(struct linux_binprm *bprm)
{
    ...

    /* 获取ELF头部信息 */
    elf_ex = (struct elfhdr *)bprm->buf;

    /* 检查ELF头部的有效性 */
    if (memcmp(elf_ex->e_ident, ELFMAG, SELFMAG) != 0)
        return -ENOEXEC;

    /* 读取程序头表 */
    elf_phdata = load_elf_phdrs(elf_ex, bprm->file);
    if (!elf_phdata)
        return -ENOMEM;

    /* 设置程序的内存布局 */
    for (i = 0; i < elf_ex->e_phnum; i++) {
        struct elf_phdr *elf_ppnt = &elf_phdata[i];

        if (elf_ppnt->p_type == PT_LOAD) {
            error = elf_load_segment(bprm->file, bprm->vma, elf_ppnt, ...);
            ...
            if (!load_addr_set) {
                load_addr_set = 1;
                load_addr = elf_ppnt->p_vaddr - elf_ppnt->p_offset;
            }
        }
        ...
    }

    /* 设置二进制的bss和brk */
    elf_bss = ...;
    elf_brk = ...;

    /* 设置开始和结束代码/数据地址 */
    start_code = ...; end_code = ...;
    start_data = ...; end_data = ...;

    /* 设置进程的入口点 */
    bprm->p = arch_align_stack(bprm->p);
    bprm->exec = bprm->p;
    retval = setup_arg_pages(bprm, ...);
    ...
    install_exec_creds(bprm);
    ...
    set_binfmt(&elf_format);

    /* 设置新的堆栈 */
    retval = setup_new_exec(bprm);
    ...

    /* 更新当前进程的信息 */
    current->mm->start_code = start_code;
    current->mm->end_code = end_code;
    current->mm->start_data = start_data;
    current->mm->end_data = end_data;
    current->mm->start_brk = current->mm->brk = elf_brk;
    current->mm->start_stack = bprm->p;

    /* 设置进程的入口地址 */
    current->mm->start_stack = bprm->p;
    retval = arch_setup_additional_pages(bprm, ...);
    ...
    start_thread(regs, elf_ex->e_entry, bprm->p); // 开始准备在用户态执行进程，这个函数是跟架构有关的
    ...
    return 0;
}

而start_thread则最会调用到start_thread_common，最终设置用户态进程的函数指针，从而在切回用户态时，开始执行我们加载的二进制文件。

static void
start_thread_common(struct pt_regs *regs, unsigned long new_ip,
		    unsigned long new_sp,
		    unsigned int _cs, unsigned int _ss, unsigned int _ds)
{
	WARN_ON_ONCE(regs != current_pt_regs());

	if (static_cpu_has(X86_BUG_NULL_SEG)) {
		/* Loading zero below won't clear the base. */
		loadsegment(fs, __USER_DS);
		load_gs_index(__USER_DS);
	}

	reset_thread_features();

	loadsegment(fs, 0);
	loadsegment(es, _ds);
	loadsegment(ds, _ds);
	load_gs_index(0);

    /*更新函数的指针地址，保证切回用户态时会执行新进程（二进制文件）*/
	regs->ip		= new_ip;
	regs->sp		= new_sp;
	regs->cs		= _cs;
	regs->ss		= _ss;
	regs->flags		= X86_EFLAGS_IF;
}

3、进程销毁

3.1-exit

我们在用户态中经常通过exit()函数来实现进程的退出，这个sys_call被定义在了kernel/exit.c，因此exit使用来结束自己身进程的。

SYSCALL_DEFINE1(exit, int, error_code)
{
	do_exit((error_code&0xff)<<8);
}

进程主动退出的时候，会执行do_exit相关逻辑，这里会主动处理掉进程在linux kernel中的相关资源，值得注意的是这是一个noreturn的函数。

void __noreturn do_exit(long code)
{
	struct task_struct *tsk = current;
	int group_dead;

	WARN_ON(irqs_disabled()); // 在中断执行过程中关闭中断，避免流程被打断。

	synchronize_group_exit(tsk, code); // 处理进程组的退出同步
	......
	coredump_task_exit(tsk); // 转存当前进程的coredump
	......
	exit_signals(tsk);  /* 用来处理退出信号 */
	.....
	group_dead = atomic_dec_and_test(&tsk->signal->live);
	if (group_dead) { // 如果一个group之中的所有进程都消亡了，就做更多的事情
		......
#ifdef CONFIG_POSIX_TIMERS
		hrtimer_cancel(&tsk->signal->real_timer); // 取消定时器
		exit_itimers(tsk);
#endif
		if (tsk->mm)
			setmax_mm_hiwater_rss(&tsk->signal->maxrss, tsk->mm); // 增加内存最大的rss
	}
	......
	taskstats_exit(tsk, group_dead); // 在退出时收集任务统计信息

	exit_mm(); // 退出内存
	......
	exit_sem(tsk); // 释放进程使用的信号量
	exit_shm(tsk); // 释放进程使用的共享内存
	exit_files(tsk);// 释放进程使用的文件描述符
	exit_fs(tsk);// 释放进程使用的文件系统
	if (group_dead)
		disassociate_ctty(1); // 取消进程的controlling tty
	exit_task_namespaces(tsk); // 释放进程的命名空间
	exit_task_work(tsk); // 处理进程绑定的task_work
	exit_thread(tsk); // 处理线程相关的工作
	......
	flush_ptrace_hw_breakpoint(tsk); // 清除硬件断点
	.....
	exit_notify(tsk, group_dead); // 通知其他进程这个进程已经退出，并且会通知父进程绑定好的task->sig
	proc_exit_connector(tsk); // 发送进程退出的连接器事件
	mpol_put_task_policy(tsk); // 释放进程的内存策略
	......
	debug_check_no_locks_held(); // 检查当前有没有持锁被异常释放了

	if (tsk->io_context)
		exit_io_context(tsk); // 释放进程的io资源

	if (tsk->splice_pipe)
		free_pipe_info(tsk->splice_pipe); // 释放进程的splice管道

	if (tsk->task_frag.page)
		put_page(tsk->task_frag.page); // 释放进程的任务片段页

	validate_creds_for_do_exit(tsk); // 验证进程的`creds`
	exit_task_stack_account(tsk); 

	check_stack_usage(); // 检查栈的使用情况
	preempt_disable(); // 禁止内核抢占
	if (tsk->nr_dirtied) // 如果进程有脏页
		__this_cpu_add(dirty_throttle_leaks, tsk->nr_dirtied); // 添加到当前CPU的dirty_throttle_leaks计数，方便后续回收
	exit_rcu();
	exit_tasks_rcu_finish();

	lockdep_free_task(tsk); // 释放进程的锁依赖信息
	do_task_dead(); // 将当前进标记为已死亡（TASK_DEAD）
}

这里值得一提的是creds（即凭据）是一个表示进程安全属性的结构，包含了进程的用户ID、组ID、附加组ID、安全能力等信息。这些信息用于决定进程可以访问哪些资源以及执行哪些操作。

而do_exit通过调用exit_notify中的do_notify_parent用SIG通过父进程子进程已经消亡了。

3.2-wait4

另外还有一个wait4，是父进程用来调用，等待子进程消亡，也就是我们之前说到的由父进程为子进程进行收尸。

SYSCALL_DEFINE4(wait4, pid_t, upid, int __user *, stat_addr,
		int, options, struct rusage __user *, ru)
{
	struct rusage r;
	long err = kernel_wait4(upid, stat_addr, options, ru ? &r : NULL);

	if (err > 0) {
		if (ru && copy_to_user(ru, &r, sizeof(struct rusage)))
			return -EFAULT;
	}
	return err;
}

而wait4->kernel_wait4->do_wait->__do_wait->do_wait_pid->wait_consider_task->wait_task_zombie->release_task，按照上述流程调用，最终释放掉task_struct结构体。

static long do_wait(struct wait_opts *wo)
{
	int retval;

	trace_sched_process_wait(wo->wo_pid);

	init_waitqueue_func_entry(&wo->child_wait, child_wait_callback); // 初始化一个waitqueue
	wo->child_wait.private = current;
	add_wait_queue(&current->signal->wait_chldexit, &wo->child_wait); // 把自己加入到这个队列上

	do {
		set_current_state(TASK_INTERRUPTIBLE);
		retval = __do_wait(wo); // 进入循环等待
		if (retval != -ERESTARTSYS)
			break;
		if (signal_pending(current)) // 父进程如果有其他信号处理，则退出
			break;
		schedule(); // 等待的时候让出调度
	} while (1); // 循环等待子进程消亡

	__set_current_state(TASK_RUNNING);
	remove_wait_queue(&current->signal->wait_chldexit, &wo->child_wait);
	return retval;
}

再wait4中会将类型设置为PIDTYPE_TGID，因此最终会调用do_wait_pid。

另外如果父进程没有显示的调用wait4等等处理函数，则会在信号处理的流程中处理消亡进程发送过来的信号，并对子进程的"遗体"进行处理，个人理解，父进程可以绑定一个SIGCHLD的处理器，这样当父进程接到信号SIGCHLD的时候就会调用类似于wait4的api对子进程进行处理。类似于exit_to_user_mode_loop中

static unsigned long exit_to_user_mode_loop(struct pt_regs *regs,
					    unsigned long ti_work)
{
	......
		if (ti_work & (_TIF_SIGPENDING | _TIF_NOTIFY_SIGNAL))
			arch_do_signal_or_restart(regs); // 如果有信号，则处理下这个信号
  ......
}

另外还有中断返回时也会处理信号量，信号处理的详细流程可以参考以后的信号量分析。

3.3-二者区别

1. 作用对象

• exit: 由当前进程调用，用于结束自身。
• wait4: 由父进程调用，用于等待子进程结束。

2. 作用结果

• exit: 导致调用它的进程结束。
• wait4: 并不结束任何进程，而是等待其他进程结束。

3. 进程间通信

• exit 提供了一种通过退出状态与父进程通信的方式。
• wait4 使父进程能够获取子进程的退出状态。

4. 资源管理

• exit 触发资源的释放。
• wait4 确保这些资源被系统回收。

kthread是指代特殊的在内核态运行的线程，其创建、管理的逻辑与普通集成有所区别，但在调度上还是与其他进程或者线程是类似的。

1、创建

内核线程的创建主要是通过kthread_create，另外kthread_run也可创建线程，区别是在创建的同时还会直接运行这个线程。

可以看到kthread_create的实际原型是kthread_create_on_node。

#define kthread_create(threadfn, data, namefmt, arg...) \
	kthread_create_on_node(threadfn, data, NUMA_NO_NODE, namefmt, ##arg)

最终会调用到__kthread_create_on_node进行创建，而实际上创建kthread的工作实际上是一个由kthreadd_task线程完成

struct task_struct *__kthread_create_on_node(int (*threadfn)(void *data),
						    void *data, int node,
						    const char namefmt[],
						    va_list args)
{
	DECLARE_COMPLETION_ONSTACK(done);
	struct task_struct *task;
	struct kthread_create_info *create = kmalloc(sizeof(*create), 
						     GFP_KERNEL); // 创建一个ktherad_create数据上下文

	if (!create)
		return ERR_PTR(-ENOMEM);
  /*填充create结构体*/
	create->threadfn = threadfn; // kthread的实际逻辑函数指针
	......
	spin_lock(&kthread_create_lock);
	list_add_tail(&create->list, &kthread_create_list); // 把创建好的create结构体加入到链表上
	spin_unlock(&kthread_create_lock);

	wake_up_process(kthreadd_task); // 唤醒创建kthread的线程
	......
	if (unlikely(wait_for_completion_killable(&done))) { // 使用wait_for循环等待创建工作结束
		......
		wait_for_completion(&done);
	}
	task = create->result;
free_create:
	kfree(create);
	return task;
}

而这个进程是在init的创建流程中被创建的，实际是真正执行的原型是kthreadd

	noinline void __ref __noreturn rest_init(void)
{
  ......
	numa_default_policy();
	pid = kernel_thread(kthreadd, NULL, NULL, CLONE_FS | CLONE_FILES);
	rcu_read_lock();
	kthreadd_task = find_task_by_pid_ns(pid, &init_pid_ns);
	rcu_read_unlock();
  ......
}

我们可以看到kthreadd的主要工作就是遍历kthread_create_list链表创建线程。

int kthreadd(void *unused)
{
	......
	set_cpus_allowed_ptr(tsk, housekeeping_cpumask(HK_TYPE_KTHREAD)); // 设置cpu亲核性
	set_mems_allowed(node_states[N_MEMORY]); // 设置内存节点
	......
	for (;;) {
		set_current_state(TASK_INTERRUPTIBLE); // 先把自身设置成休眠
		if (list_empty(&kthread_create_list)) // 如果没有需要创建的线程，就让出调度
			schedule();
		__set_current_state(TASK_RUNNING); // 有线程需要创建则重新设置成running

		spin_lock(&kthread_create_lock);
		while (!list_empty(&kthread_create_list)) { // 遍历链表
			struct kthread_create_info *create;

			create = list_entry(kthread_create_list.next,
					    struct kthread_create_info, list);
			list_del_init(&create->list);
			spin_unlock(&kthread_create_lock);

			create_kthread(create); // 创建这个线程

			spin_lock(&kthread_create_lock);
		}
		spin_unlock(&kthread_create_lock);
	}

	return 0;
}

创建的实际逻辑比较简单，就是通过fork.c里通过kernel_thread创建线程。

static void create_kthread(struct kthread_create_info *create)
{
	int pid;

#ifdef CONFIG_NUMA
	current->pref_node_fork = create->node;
#endif
	/* We want our own signal handler (we take no signals by default). */
	pid = kernel_thread(kthread, create, create->full_name,
			    CLONE_FS | CLONE_FILES | SIGCHLD); // 通过fork.c中的kernel_thread创建线程
	if (pid < 0) {
		/* Release the structure when caller killed by a fatal signal. */
		struct completion *done = xchg(&create->done, NULL);

		kfree(create->full_name);
		if (!done) {
			kfree(create);
			return;
		}
		create->result = ERR_PTR(pid);
		complete(done); // 填充create->done结构体
	}
}

2、kthread()

2.1-int kthread(void *_create)

kthread()函数是由kernel_thread在创建线程时绑定的，内核线程创建完会一直则执行ret = threadfn(data);

static int kthread(void *_create)
{
	/* Copy data: it's on kthread's stack */
	struct kthread_create_info *create = _create;
	int (*threadfn)(void *data) = create->threadfn; // kthread实际业务逻辑
	void *data = create->data;
	struct kthread self; // kthread特别的数据结构
	int ret;
  
  self = to_kthread(current); // 填充kthread结构体

	/* OK, tell user we're spawned, wait for stop or wakeup */
	__set_current_state(TASK_UNINTERRUPTIBLE); // 先休眠
	......
	if (!test_bit(KTHREAD_SHOULD_STOP, &self.flags)) {
		__kthread_parkme(&self);
		ret = threadfn(data); // 开始执行具体ktread逻辑
	}
	/* we can't just return, we must preserve "self" on stack */
	do_exit(ret);
}

2.2-struct kthread

而struct kthread是一个内核线程专有的数据结果，这里会保存内核线程需要操作的基本数据结构

struct kthread {
	unsigned long flags; // 线程的状态（如运行、休眠等）
	unsigned int cpu; // 线程绑定的cpu
	int result; // 线程的return值
	int (*threadfn)(void *); // 线程实际执行逻辑函数地址
	void *data; // 存储或传递给线程函数的数据
	struct completion parked; // 用来记录线程暂停的结构体
	struct completion exited; // 用来记录线程退出的结构体
#ifdef CONFIG_BLK_CGROUP
	struct cgroup_subsys_state *blkcg_css; // 指向cgroup状态的指针，用于块设备控制组相关的功
#endif
	/* To store the full name if task comm is truncated. */
	char *full_name; // 线程名称
};

3、唤醒&退出

3.1-唤醒

由于很多内核线程都是阶段运行的，所以部分内核线程会主动进入休眠状态，然后等待其他线程唤醒。

唤醒的方式比较常见，就是通过wake_up_process来唤醒进程。

3.2-退出

3.2.1-正常退出

如上述分析，kthread正常退出后会执行kthread_exit(ret);

static int kthread(void *_create)
{
	......
	/* OK, tell user we're spawned, wait for stop or wakeup */
	__set_current_state(TASK_UNINTERRUPTIBLE);
	create->result = current;
	complete(&create->done);
	schedule();

	ret = -EINTR;

	if (!test_bit(KTHREAD_SHOULD_STOP, &self.flags)) {
		__kthread_parkme(&self);
		ret = threadfn(data);
	}
	/* we can't just return, we must preserve "self" on stack */
	kthread_exit(ret);
}

而kthread_exit中则会填充done相关的结构体

void __noreturn kthread_exit(long result)
{
	struct kthread *kthread = to_kthread(current);
	kthread->result = result;
	do_exit(0);
}

kthread->exited的结构体最终是由mm_release完成的，调用流程为：do_exit->exit_mm->exit_mm_release->mm_release，其中操作如下：

static void mm_release(struct task_struct *tsk, struct mm_struct *mm)
{
	uprobe_free_utask(tsk);
	......
	/*
	 * All done, finally we can wake up parent and return this mm to him.
	 * Also kthread_stop() uses this completion for synchronization.
	 */
	if (tsk->vfork_done)
		complete_vfork_done(tsk); // 通过操作vfork_done地址来填充结构体
}

上边的vfork_done是在初始化过程中，指向exited结构体的

bool set_kthread_struct(struct task_struct *p)
{
	......
	init_completion(&kthread->exited);
	init_completion(&kthread->parked);
	p->vfork_done = &kthread->exited;
	......
}

3.2.2-kthread_stop

另外，我们也可以主动调用kthread_stop()来终止一个循环线程，但是同时也要再线程的循环中增加kthread_should_stop()的检查。

int kthread_stop(struct task_struct *k)
{
	struct kthread *kthread;
	int ret;

	trace_sched_kthread_stop(k);

	get_task_struct(k);
	kthread = to_kthread(k); // 获取线程的kthread结构体
	set_bit(KTHREAD_SHOULD_STOP, &kthread->flags); // 增加should_stop flag
	kthread_unpark(k); // 取消park flag
	set_tsk_thread_flag(k, TIF_NOTIFY_SIGNAL); // 提前取消signal peding
	wake_up_process(k); // 唤醒线程
	wait_for_completion(&kthread->exited); // 等待线程完成
	ret = kthread->result; // 把return存入结构体中
	put_task_struct(k); // 解引用

	trace_sched_kthread_stop_ret(ret);
	return ret;
}

其中比较关键的操作是wait_for_completion，他会执行一个没有timeout的循环等待，等待进程退出。

void __sched wait_for_completion(struct completion *x)
{
	wait_for_common(x, MAX_SCHEDULE_TIMEOUT, TASK_UNINTERRUPTIBLE);
}
EXPORT_SYMBOL(wait_for_completion);

static long __sched
wait_for_common(struct completion *x, long timeout, int state)
{
	return __wait_for_common(x, schedule_timeout, timeout, state);
}

static inline long __sched
do_wait_for_common(struct completion *x,
		   long (*action)(long), long timeout, int state)
{
	if (!x->done) {
		DECLARE_SWAITQUEUE(wait);

		do {
			if (signal_pending_state(state, current)) { // 有信号排队的时候退出循环
				timeout = -ERESTARTSYS;
				break;
			}
			__prepare_to_swait(&x->wait, &wait);
			__set_current_state(state); // 把本线程标记为不可中断的状态，防止误调度
			raw_spin_unlock_irq(&x->wait.lock);
			timeout = action(timeout); // 不会重新唤醒，应为timeout是MAX_SCHEDULE_TIMEOUT
			raw_spin_lock_irq(&x->wait.lock);
		} while (!x->done && timeout); // 等待kthread的done标记为置1，由do_exit完成
		__finish_swait(&x->wait, &wait);
		if (!x->done)
			return timeout;
	}
	if (x->done != UINT_MAX)
		x->done--;
	return timeout ?: 1;
}

内核编译以及工具开发过程中，经常会涉及到Makefile文件，这一次详细来看一下Makefile相关的内容。

官方手册：Learn Makefiles

很好的学习文章：跟我一起写Makefile

1、入门

1.1-Makefile的作用

编译一个最简单的.c文件通常会使用到

gcc main.c

但是在大型复杂项目在构建的时候，需要的依赖文件比较多且复杂，这个时候只用gcc简单的进行编译已经无法实现了。另外Makefile还会用于帮助决定大型程序的哪些部分需要重新编译，这样只有一个模块文件修改时，就没必要重编整个工程。

而Makefile依赖的工具则是make，他会寻找当前路径下的Makefile文件，并执行相应的命令。Makefile则告诉make命令需要怎么样的去编译和链接程序。

1.2-Makefile的基础规则

一个Makefile的最基础组成如下

target ... : prerequisites ...
    recipe
    ...
    ...

这其中：

• target：

  可以是一个object file（目标文件），也可以是一个可执行文件，还可以是一个标签（label）。

• prerequisites：

  生成该target所依赖的文件，可以理解为原材料。

• recipe：

  生成这个target要执行的命令（任意的shell命令）。

如果原材料中有代码变更的话，就会执行相应的的命令，重新构建目标。

1.3-例子

c: a.o b.o
	gcc -o c a.o b.o

a.o：a.c d.h
	gcc a.c
 
b.o: b.c d.h
	gcc b.c

上边的例子可以看到，我们会最终编译出一个c的二进制文件，而c是由a.c与b.c两个c文件组成的，因此需要将他们编译出的.o文件进行链接，而这两个.o文件还是与d.h有关，所有当时d.h有变化时，则会重编整个工程。

2、规则

例如我们之前的举例，最基础的规则如下

foo.o: foo.c defs.h       # foo模块
    cc -c -g foo.c

在规则中，使用\进行换行，使用*进行通配。

2.1-伪目标

如果目标后没有依赖文件，则相当于一个lable

clean :
    rm *.o

在执行make clean后则会执行对应的命令，也就是清理所有的.o文件。

另外也可以使用下列方式指定特定目标为伪目标

.PHONY : clean
clean :
    rm *.o

2.2-多目标

makefile中可以多个目标依赖一样的文件，下列这两个种方式是等价的

a b : c.o d.o
...
a : c.o d.o
b : c.o d.o

2.3-自动生成依赖

在Makefile中，我们可以利用GCC的-M选项生成依赖关系，然后通过-include指令将这些依赖关系包含到Makefile中。这样，当源文件或头文件发生变化时，Makefile会自动重新编译相应的目标文件。例如

# 定义变量
CC = gcc
CFLAGS = -Wall -g
SRCS = $(wildcard *.c)
OBJS = $(patsubst %.c,%.o,$(SRCS))
DEPS = $(patsubst %.c,%.d,$(SRCS))
TARGET = my_program

# 默认目标
all: $(TARGET)

# 链接目标文件，生成可执行文件
$(TARGET): $(OBJS)
	$(CC) $(CFLAGS) -o $(TARGET) $(OBJS)

# 编译源文件，生成目标文件和依赖文件
%.o: %.c
	$(CC) $(CFLAGS) -MMD -c $*.c -o $*.o

# 包含自动生成的依赖文件
-include $(DEPS)

3、变量

3.1-基础变量

在Makefile中，变量的语法与shell类似，比如

1. 定义编译的文件

object = a.o b.o
c: $(object)
	gcc -o c $(object)

2. 定义命令

cc = gcc
c: a.o b.o
	$(cc) -o c a.o b.o

3.2-追加变量

可以使用+=的方式追加变量

object = a.o b.o
object += c.o

这个时候object = a.o b.o c.o。

3.3-传参

如果Makefile中没有定义变量的话，可以通过make DESTDIR=xxx的时候传入变量，

install -d $(DESTDIR)/usr/local/sbin/

类似上述命令组中会安装在xxx/usr/local/sbin/上。

3.4-替换

下列操作中，会把变量 $(sources) 所有 .c 的字串都替换成 .d

sources = foo.c bar.c

include $(sources:.c=.d)

3.5-自动变量

$@：表示当前规则的目标文件。在命令行中，我们可以用$@引用目标文件，而无需显式地指定目标文件名。

$^：表示当前规则的所有依赖文件，以空格分隔。在命令行中，我们可以用$^引用所有依赖文件，而无需显式地指定它们。

$<：表示当前规则的第一个依赖文件。在命令行中，我们可以用$<引用第一个依赖文件，而无需显式地指定它。

4、if判断

最基础的语法是

<conditional-directive>
<text-if-true>
else
<text-if-false>
endif

Makefile中有四种if语法及<conditional-directive>

1. 是否相等

ifeq (<arg1>, <arg2>)

2. 是否不相等

ifneq (<arg1>, <arg2>)

3. 是否为空

ifdef arg1

4. 是否不为空

ifndef arg1

上述的参数可以是变量，也可以是字符串，类似于判断 $(CC) 变量是否 gcc

ifeq ($(CC),gcc)

5、命令

Makefile中可以直接执行bash命令，但是命令必须以tab开头。

5.1-显示命令

makefile可以通过@来屏蔽输出命令本身。比如makefie中存在这样一个命令

test:
	echo 123
	@echo 456

运行这个脚本的效果如下

echo 123
123
456

另外，也可以通过make -s来屏蔽命令输出，用make -n只输出命令，不执行命令（用于调试）。

5.2-忽略报错

在makefile中，如果命令执行失败，则会退出makefile，不继续执行，而-命令则可以忽略报错继续执行。

test:
	abc
	echo 123

这时

# make test
abc
make: abc: Command not found
make: *** [Makefile:2: test] Error 127

而添加了-

test:
	-abc
	echo 123

则会

# make test
abc
make: abc: Command not found
make: [Makefile:2: test] Error 127 (ignored)
echo 123
123

不是，这也太好看了

主要分析内存的分配机制

https://blog.csdn.net/m0_65931372/article/details/126234314

1、内存结构

引自Linux 物理内存管理涉及的三大结构体之struct page

1.1 页 page

在linux kernel中，内存分配的最基本单位为页，也就是数据结构struct page，可以理解为每一个页对应着一个物理内存单元，通常为4KB。

下边是linux/mm_types.h定义的数据原型，在忽略一部分内容后，具体的代码如下。

struct page {
	unsigned long flags;		/* Atomic flags, some possibly
					 * updated asynchronously */
	/*
	 * Five words (20/40 bytes) are available in this union.
	 * WARNING: bit 0 of the first word is used for PageTail(). That
	 * means the other users of this union MUST NOT use the bit to
	 * avoid collision and false-positive PageTail().
	 */
	union {
    struct list_head lru;
    /* See page-flags.h for PAGE_MAPPING_FLAGS */
    struct address_space *mapping;
    pgoff_t index;		/* Our offset within mapping. */
    /**
     * @private: Mapping-private opaque data.
     * Usually used for buffer_heads if PagePrivate.
     * Used for swp_entry_t if PageSwapCache.
     * Indicates order in the buddy system if PageBuddy.
     */
    unsigned long private;
		......
	};
	union {		/* This union is 4 bytes in size. */
    /*	
		 * If the page can be mapped to userspace, encodes the number
		 * of times this page is referenced by a page table.
		 */
    atomic_t _mapcount;
		.....
	};

	/* Usage count. *DO NOT USE DIRECTLY*. See page_ref.h */
	atomic_t _refcount;
	......
#if defined(WANT_PAGE_VIRTUAL)
	void *virtual;			/* Kernel virtual address (NULL if
					   not kmapped, ie. highmem) */
#endif /* WANT_PAGE_VIRTUAL */
	......
} _struct_page_alignment;

其中各个域的含义如下：

• flags：表示当前页的状态。
• lru：当前页表中的lru（Least Recently Used，最近最少使用）链表，用来作为页替换的依据。
• mapping：作为page cache时page的具体地址（指向和这个页关联的addresss_space）。
• _mapcount：被映射的计数。
• _refcount：页的引用计数，表示当前这段内存也正在被多少进程引用。
• virtual：页在虚拟内存中的地址。

此外，可以把每一个物理页的基本单位是物理页帧，而每一个物理页帧都有自己的pfn物理页帧号，下边是物理页帧号和page以及物理页地址的转换关系

#define __pfn_to_page(pfn)	(mem_map + ((pfn) - ARCH_PFN_OFFSET))
#define __page_to_pfn(page)	((unsigned long)((page) - mem_map) + \
				 ARCH_PFN_OFFSET)

1.2 区 zone

内存分区的原因在于，不同的硬件只能访问特定范围的内存，比如ISA总线的DMA就要求只能访问前16MB的内存。

因此基于硬件的限制，linux kernel内存整体分为如下几个区：(被定义在了include/linux/mmzone.h的enum zone_type中)

• ZONE_DMA（0~16MB）

  这个区域包含了适用于直接内存访问（Direct Memory Access, DMA）的内存。DMA是一种数据传输方式，可以在不经过CPU的情况下，直接在内存和外设之间传输数据。ZONE_DMA通常包含较低的物理地址空间，这是因为许多早期的外设只支持有限的地址范围进行DMA传输。

• ZONE_DMA32

  这个区域包含了适用于32位DMA设备的内存。这些设备可以访问较大的地址范围，通常高达4GB。ZONE_DMA32主要用于64位系统，因为在32位系统中，ZONE_NORMAL通常就足以满足DMA设备的需求。

• ZONE_NORMAL（16MB~896MB）

  Why Linux Kernel ZONE_NORMAL is limited to 896 MB?

  这个区域包含了常规内存，可以被内核和用户空间进程使用。它不包括用于DMA的内存，因此可以避免与需要特定地址范围的DMA设备发生冲突。在32位系统中，ZONE_NORMAL通常包含了除ZONE_DMA之外的所有内存。

• ZONE_HIGHEM（896MB~4GB）

  这个区域包含了高端内存（high memory），即那些不能被内核直接映射到其线性地址空间的内存。在具有大量物理内存的32位系统上，内核地址空间可能不足以映射所有内存，因此需要将部分内存放入ZONE_HIGHMEM。64位系统通常不需要使用这个区域，因为它们具有足够大的地址空间。

• ZONE_MOVABLE

  这个区域包含了可移动内存。当系统需要连续的物理内存块时，内核可以将ZONE_MOVABLE中的页面迁移到其他区域，从而腾出连续的内存空间。这对于支持内存热插拔（hotplug）和大内存分配的系统非常有用。

• CONFIG_ZONE_DEVICE

  用于支持设备专用内存（device memory）。这种内存通常不是由通用内存子系统管理的，而是由特定的设备驱动程序管理。将设备内存纳入ZONE_DEVICE允许内核将这些设备内存纳入内存管理子系统，从而可以在需要时将其用于其他目的，设备专用内存的一个例子是显卡的显存。

1.3 节点 node

对于NUMA架构的系统中，还会将内存的管理增加一个node节点，node节点是比zone更高级的管理层级。从下边的数据结构中可以看出，表示存放node的数据结构pglist_data中前几个域都是用来记录zone的。而对于uma的系统，相当于只有一个node节点的系统，故只有一个pglist_data数据结构。

对于常见的系统的来说，会存在numa0和numa1两个node。

但是区分于内存中的zone，node的结构在linux内是由软件区分的，而不是每一个node实际由自己的各个内存zone。

/*
 * On NUMA machines, each NUMA node would have a pg_data_t to describe
 * it's memory layout. On UMA machines there is a single pglist_data which
 * describes the whole memory.
 *
 * Memory statistics and page replacement data structures are maintained on a
 * per-zone basis.
 */
typedef struct pglist_data {
	/*
	 * node_zones contains just the zones for THIS node. Not all of the
	 * zones may be populated, but it is the full list. It is referenced by
	 * this node's node_zonelists as well as other node's node_zonelists.
	 */
	struct zone node_zones[MAX_NR_ZONES]; // 管理区描述符的数组

	/*
	 * node_zonelists contains references to all zones in all nodes.
	 * Generally the first zones will be references to this node's
	 * node_zones.
	 */
	struct zonelist node_zonelists[MAX_ZONELISTS]; // 页分配器所使用的数组

	int nr_zones; /* 管理区的数目 */
#ifdef CONFIG_FLATMEM	/* means !SPARSEMEM */
	struct page *node_mem_map; // 节点中页描述符数组
	......
#endif
#if defined(CONFIG_MEMORY_HOTPLUG) || defined(CONFIG_DEFERRED_STRUCT_PAGE_INIT)
	......
#endif
	unsigned long node_start_pfn; // 节点中第一个页框的下标
	unsigned long node_present_pages; /* total number of physical pages */
	unsigned long node_spanned_pages; /* total size of physical page
					     range, including holes */
	int node_id; // 节点表示符
	wait_queue_head_t kswapd_wait; // kswapd页换出守护进程的等待队列
    ......
	struct task_struct *kswapd;	/* 内核的kswapd进程描述符 */
	int kswapd_order; // kswapd要创建的空闲块大小
	......
#ifdef CONFIG_COMPACTION
    ......
#endif
	......
#ifdef CONFIG_NUMA
	/*
	 * node reclaim becomes active if more unmapped pages exist.
	 */
	unsigned long		min_unmapped_pages;
	unsigned long		min_slab_pages;
#endif /* CONFIG_NUMA */

	/* Write-intensive fields used by page reclaim */
	CACHELINE_PADDING(_pad1_);

#ifdef CONFIG_DEFERRED_STRUCT_PAGE_INIT
	......
#endif /* CONFIG_DEFERRED_STRUCT_PAGE_INIT */
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
	struct deferred_split deferred_split_queue;
#endif

#ifdef CONFIG_NUMA_BALANCING
	......
#endif
	......
	/* Per-node vmstats */
	struct per_cpu_nodestat __percpu *per_cpu_nodestats; // 用来描述node状态的数据
	atomic_long_t		vm_stat[NR_VM_NODE_STAT_ITEMS];
	......
} pg_data_t;

在X86中，使用node_data来存储所有node中的pglist_data数据结构，其中nid就是表示numa的id。

extern struct pglist_data *node_data[];
#define NODE_DATA(nid)		(node_data[nid])

2、页分配函数

2.1 请求page

alloc_pages使用来分配对应的物理页帧的函数，实际上大部分部分操作是不需要去分配物理内存的，因为物理内存已经分配好，直接从内存池中直接拿即可（后边会详细分析）。

#ifdef CONFIG_NUMA
struct page *alloc_pages(gfp_t gfp, unsigned int order);
......
#else
static inline struct page *alloc_pages(gfp_t gfp_mask, unsigned int order)
{
	return alloc_pages_node(numa_node_id(), gfp_mask, order);
}
#endif

可以看到，对于NUMA的系统来说，在进行页面分配的时，会根据mempolicy执行三种不同的分配逻辑，而该策略主要是定义在当前运行的进程中。

• MPOL_INTERLEAVE

  表示交错内存分配策略。在这种策略下，内核会在指定的一组NUMA节点间交错分配内存。这意味着连续的内存页会被分散到不同的NUMA节点上，从而实现内存访问负载的均衡。这种策略适用于访问模式为顺序访问的应用程序，例如流式处理（streaming）应用程序，因为它可以有效地利用多个节点的内存带宽，同时减小单个节点的内存访问压力。

• MPOL_PREFERRED_MANY

  表示优先多节点内存分配策略。在这种策略下，内核会优先在指定的多个NUMA节点中分配内存。当内存需求无法在优先节点上得到满足时，内核会尝试在其他节点上分配内存。这种策略适用于对内存访问延迟敏感的应用程序，因为它可以确保内存分配尽可能地靠近优先的NUMA节点，从而减小内存访问延迟。

struct page *alloc_pages(gfp_t gfp, unsigned order)
{
	struct mempolicy *pol = &default_policy;
	struct page *page;

	if (!in_interrupt() && !(gfp & __GFP_THISNODE))
		pol = get_task_policy(current);

	/*
	 * No reference counting needed for current->mempolicy
	 * nor system default_policy
	 */
	if (pol->mode == MPOL_INTERLEAVE)
		page = alloc_page_interleave(gfp, order, interleave_nodes(pol));
	else if (pol->mode == MPOL_PREFERRED_MANY)
		page = alloc_pages_preferred_many(gfp, order,
				  policy_node(gfp, pol, numa_node_id()), pol);
	else
		page = __alloc_pages(gfp, order,
				policy_node(gfp, pol, numa_node_id()),
				policy_nodemask(gfp, pol));

	return page;
}
EXPORT_SYMBOL(alloc_pages);

如果是一个不支持NUMA的系统，则通过一列调用，最终会调用到alloc_pages->alloc_pages_node->__alloc_pages_node->__alloc_pages，其实最终的差别就是只为了一个NUMA进行分配。

通过注释可以看到，alloc其实是从伙伴系统核心部分，它用于分配连续的物理内存页。

/*
 * This is the 'heart' of the zoned buddy allocator.
 */
struct page *__alloc_pages(gfp_t gfp, unsigned int order, int preferred_nid,
							nodemask_t *nodemask)
{
	......
	/*
	 * Apply scoped allocation constraints. This is mainly about GFP_NOFS
	 * resp. GFP_NOIO which has to be inherited for all allocation requests
	 * from a particular context which has been marked by
	 * memalloc_no{fs,io}_{save,restore}. And PF_MEMALLOC_PIN which ensures
	 * movable zones are not used during allocation.
	 */
	gfp = current_gfp_context(gfp); // 获取当前的请求页框的标志
	alloc_gfp = gfp;
	......

	/* First allocation attempt */
	page = get_page_from_freelist(alloc_gfp, order, alloc_flags, &ac); // 尝试直接从伙伴系统中拿到空闲页
	if (likely(page))
		goto out;
	......
	page = __alloc_pages_slowpath(alloc_gfp, order, &ac); // 伙伴系统中没找到则进行慢速分配
out:
	......
	return page;
}
EXPORT_SYMBOL(__alloc_pages);

请求页的标志位被定义在了include/linux/gfp_types.h

#define __GFP_RECLAIMABLE ((__force gfp_t)___GFP_RECLAIMABLE)
#define __GFP_WRITE	((__force gfp_t)___GFP_WRITE)
#define __GFP_HARDWALL   ((__force gfp_t)___GFP_HARDWALL)
#define __GFP_THISNODE	((__force gfp_t)___GFP_THISNODE)
#define __GFP_ACCOUNT	((__force gfp_t)___GFP_ACCOUNT)
#define __GFP_RECLAIMABLE ((__force gfp_t)___GFP_RECLAIMABLE)
#define __GFP_WRITE	((__force gfp_t)___GFP_WRITE)
#define __GFP_HARDWALL   ((__force gfp_t)___GFP_HARDWALL)
#define __GFP_THISNODE	((__force gfp_t)___GFP_THISNODE)
#define __GFP_ACCOUNT	((__force gfp_t)___GFP_ACCOUNT)
......

其用途主要是用来指明从哪里如何寻找空闲的页框，包括物理内存的区域，如__GFP_DMA含义是从DMA区获取空闲页，每一具体的定义在内核有详细的注释进行说明。

内核中实际上使用各种标志的组合进行内存分配，比较常用的几种具体flag如下

#define GFP_ATOMIC	(__GFP_HIGH|__GFP_KSWAPD_RECLAIM)
#define GFP_KERNEL	(__GFP_RECLAIM | __GFP_IO | __GFP_FS)
#define GFP_KERNEL_ACCOUNT (GFP_KERNEL | __GFP_ACCOUNT)
#define GFP_NOWAIT	(__GFP_KSWAPD_RECLAIM)
#define GFP_NOIO	(__GFP_RECLAIM)
#define GFP_NOFS	(__GFP_RECLAIM | __GFP_IO)
#define GFP_USER	(__GFP_RECLAIM | __GFP_IO | __GFP_FS | __GFP_HARDWALL)
#define GFP_DMA		__GFP_DMA
#define GFP_DMA32	__GFP_DMA32
#define GFP_HIGHUSER	(GFP_USER | __GFP_HIGHMEM)
#define GFP_HIGHUSER_MOVABLE	(GFP_HIGHUSER | __GFP_MOVABLE | __GFP_SKIP_KASAN)
#define GFP_TRANSHUGE_LIGHT	((GFP_HIGHUSER_MOVABLE | __GFP_COMP | \
			 __GFP_NOMEMALLOC | __GFP_NOWARN) & ~__GFP_RECLAIM)
#define GFP_TRANSHUGE	(GFP_TRANSHUGE_LIGHT | __GFP_DIRECT_RECLAIM)

而在分配的实际过程中，内核首先会尝试从伙伴系统的空闲页链表中分配内存页，如果失败了数进行慢速路径分配。这个过程可能会触发内存回收、内存压缩等操作，以便在内存紧张的情况下找到足够的空闲页。伙伴系统的部分后边详细分析，这里直接关注慢速分配路径。

具体的操作在代码中进行注释。代码很长，省略了一些代码，其中忽略了一些分配内存标志的检查，在状态不符合我们设定的状态描述符时，则会直接返回，例如我们标记了PF_MEMALLOC那么则不会尝试进行内存压缩分配。

static inline struct page *
__alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
						struct alloc_context *ac)
{
	......
restart:
  /*初始化变量，例如重试计数器、优先级等。*/
	compaction_retries = 0;
	......

	/*
	 * 根据GFP标志和order调整alloc_flags
	 */
	alloc_flags = gfp_to_alloc_flags(gfp_mask, order);
	......
	if (alloc_flags & ALLOC_KSWAPD)
		wake_all_kswapds(order, gfp_mask, ac); // 如果被标记了kswapd的回收
 
	// 还是首先尝试从伙伴系统里直接拿空闲页
	page = get_page_from_freelist(gfp_mask, order, alloc_flags, ac);
	if (page)
		goto got_pg;

	/*
	 * 如果可以直接回收并且分配的order较高或者非MIGRATE_MOVABLE类型，
	 * 尝试直接压缩内存，然后分配
	 */
	if (can_direct_reclaim &&
			(costly_order ||
			   (order > 0 && ac->migratetype != MIGRATE_MOVABLE))
			&& !gfp_pfmemalloc_allowed(gfp_mask)) {
		page = __alloc_pages_direct_compact(gfp_mask, order,
						alloc_flags, ac,
						INIT_COMPACT_PRIORITY,
						&compact_result);
		if (page)
			goto got_pg;

		/*
		 * 检查标记是不是高消耗的操作，例如透明大页的分配操作
		 */
		if (costly_order && (gfp_mask & __GFP_NORETRY)) {
			if (compact_result == COMPACT_SKIPPED ||
			    compact_result == COMPACT_DEFERRED)
				goto nopage;

			compact_priority = INIT_COMPACT_PRIORITY;
		}
	}

retry:
	/* Ensure kswapd doesn't accidentally go to sleep as long as we loop */
	if (alloc_flags & ALLOC_KSWAPD)
		wake_all_kswapds(order, gfp_mask, ac); // 在retry中再次执行一次kswapd
	......
	/* 尝试从空闲列表中分配内存页*/
	page = get_page_from_freelist(gfp_mask, order, alloc_flags, ac);
	if (page)
		goto got_pg;
	.......
	/* 执行回收page，再分配 */
	page = __alloc_pages_direct_reclaim(gfp_mask, order, alloc_flags, ac,
							&did_some_progress);
	if (page)
		goto got_pg;

	/* 执行压缩page，在分配 */
	page = __alloc_pages_direct_compact(gfp_mask, order, alloc_flags, ac,
					compact_priority, &compact_result);
	if (page)
		goto got_pg;
	......
  /*根据回收压缩的效果，判断是否要执行retry*/
	if (should_reclaim_retry(gfp_mask, order, ac, alloc_flags,
				 did_some_progress > 0, &no_progress_loops))
		goto retry;

	if (did_some_progress > 0 &&
			should_compact_retry(ac, order, alloc_flags,
				compact_result, &compact_priority,
				&compaction_retries))
		goto retry;

	/*
	 * 接下来就要执行oom了，再次之前要再确认下是不是有其他的zone或者set可以分配
	 */
	if (check_retry_cpuset(cpuset_mems_cookie, ac) ||
	    check_retry_zonelist(zonelist_iter_cookie))
		goto restart;

	/* 如果前边的操作都失败了，那么就会尝试执行oom清理一些进程来回收内存 */
	page = __alloc_pages_may_oom(gfp_mask, order, ac, &did_some_progress);
	if (page)
		goto got_pg;
  ......
	/* oom的时候会标记did_some_progress，那么此时我们就循环执行分配*/
	if (did_some_progress) { 
		no_progress_loops = 0;
		goto retry;
	}

nopage:
	/*
	 * 确认下是不是有其他的zone或者set可以分配内存
	 */
	if (check_retry_cpuset(cpuset_mems_cookie, ac) ||
	    check_retry_zonelist(zonelist_iter_cookie))
		goto restart;

	...... // 忽略了根据描述符进行的一些错误处理输出

		/*在内存保留区域中分配内存*/
		page = __alloc_pages_cpuset_fallback(gfp_mask, order, ALLOC_MIN_RESERVE, ac);
		if (page)
			goto got_pg;

		cond_resched(); // 如果还是失败，那么首先会先让出cpu，后边尝试再次分配
		goto retry;
	}
fail:
	warn_alloc(gfp_mask, ac->nodemask,
			"page allocation failure: order:%u", order);
got_pg:
	return page;
}

2.3 释放page

内核中有几个函数用于释放分配好的物理页框

• __free_pages
• fress_pages
• __free_page
• free_page

不带s的api主要是释放单独的页面，而带s则是释放连续的page。

fress_pages则会调用到__free_pages，它将连续的内存页归还给伙伴系统（buddy allocator），以便在后续的内存分配中重复使用这些内存页。

void __free_pages(struct page *page, unsigned int order)
{
	/* get PageHead before we drop reference */
	int head = PageHead(page);

	if (put_page_testzero(page)) // 递减page的引用计数
		free_the_page(page, order); // 将page还给伙伴系统
	else if (!head)// 如果不是页的头部，则循环回收复合页其他页
		while (order-- > 0)
			free_the_page(page + (1 << order), order);
}
EXPORT_SYMBOL(__free_pages);

值得说的是PageHead(page)宏来检查给定的page是否为复合页（compound page）的头部。将结果存储在head变量中。复合页是一种用于表示较大连续内存块的机制，它将多个连续的物理页组合成一个逻辑上的大页。

在具体释放的过程中，还会区分是不是per_cpu页

static inline void free_the_page(struct page *page, unsigned int order)
{
	if (pcp_allowed_order(order))		/* Via pcp? */
		free_unref_page(page, order); // 释放per_cpu页给CPU cache
	else
		__free_pages_ok(page, order, FPI_NONE); // 释放正常页
}

接下来就会遍历循环order变量，将page换个伙伴系统，具体详细的部分我们后边分析伙伴系统时进一步讨论。

Linux内核需要有效地管理内存，以支持各种类型的应用和服务。传统的内存分配方法（如连续内存分配）存在一些不足，例如内存碎片和分配效率低下。频繁的申请和释放不同大小的连续页框必然会导致已分配的页框块分散了许多小块的空闲页框，可能会产生的问题就是：即使内存页框是充足的，但要申请一个大的页框可能也会因为没有足够的连续页框而失败。

为了避免内存碎片化而引发上述问题，通常可以有两种方法：

1. 使用分页单元把不连续的页框映射到连续的线性空间。
2. 使用一种适当的技术用以记录当前连续页框的情况，避免分配小组连续页框的时候对大的页框进行切割。

为了解决上述问题，Linux内核引入了伙伴系统（Buddy System）。这主要是因为内核中确实需要连续页框，并且连续页框的存在有助于保持CPU Cache中的TLB命中率。

2、伙伴系统原理

伙伴系统通过将内存分成多个大小相等的块（block），按2的幂次方规划（称为“order”），并维护不同order的空闲块链表来工作。这种方法使得内存的分配和释放更加高效，减少了内存碎片。

伙伴系统吧内存分成了11个块链表，每个链表包含1、2、4、8、16、32、64、128、256、512和1024个连续页框即2^0~10，最大的1024个页框块则是4MB的内存大小。

2.1-关键步骤

1. 初始化：内存在系统启动时被分成块，按order组织成链表。
2. 分配：根据需求选择合适大小的块，如无合适块，则分割更大块。
3. 释放：释放的块返回链表，相邻空闲块合并。

3、伙伴系统在linux中的实现

3.1-free_area

• struct free_area：定义空闲块链表。

struct free_area {
	struct list_head	free_list[MIGRATE_TYPES]; // 连续页框的具体地址
	unsigned long		nr_free; // 有多少个空闲的对应大小的页框
};

而上述结构体被定义在了zone的结构体之中，可以看到每一个内存区里都有11个free_area结构体。

#define MAX_ORDER 10

struct zone {
  ......
	/* free areas of different sizes */
	struct free_area	free_area[MAX_ORDER + 1];
  ......
}

可以看到，free_area中第K个元素，对应这个2^k大小的连续页面，如上文原理分析，最多是2¹⁰的也就是1024个连续页框。

3.2-分配函数

前一篇文章中我们分析到内存申请和释放页框过程中是存在从伙伴系统直接获取或还原的，所以直接切入到这部分代码：

/*
 * get_page_from_freelist goes through the zonelist trying to allocate
 * a page.
 */
static struct page *
get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags,
						const struct alloc_context *ac)
{
	......
retry:
	no_fallback = alloc_flags & ALLOC_NOFRAGMENT;
	z = ac->preferred_zoneref;
  // 遍历所有内存区域（zones），寻找满足空闲页面需求的区域。
	for_next_zone_zonelist_nodemask(zone, z, ac->highest_zoneidx,
					ac->nodemask) {
		struct page *page;
		unsigned long mark;

    // 如果当前的zone不可以用的话则直接退出当前的遍历
		if (cpusets_enabled() &&
			(alloc_flags & ALLOC_CPUSET) &&
			!__cpuset_zone_allowed(zone, gfp_mask))
				continue;
		......
    // 在NUMA架构中，尽量避免远端内存的分配，如果发现不是本地的内存就再找一次
    // 即使代价是造成内存碎片化
		if (no_fallback && nr_online_nodes > 1 &&
		    zone != ac->preferred_zoneref->zone) {
			int local_nid;

			local_nid = zone_to_nid(ac->preferred_zoneref->zone);
			if (zone_to_nid(zone) != local_nid) {
				alloc_flags &= ~ALLOC_NOFRAGMENT;
				goto retry;
			}
		}

		/* 检查水位线，避免内存耗尽了 */
		if (test_bit(ZONE_BELOW_HIGH, &zone->flags))
			goto check_alloc_wmark;

		mark = high_wmark_pages(zone);
		if (zone_watermark_fast(zone, order, mark,
					ac->highest_zoneidx, alloc_flags,
					gfp_mask))
			goto try_this_zone;
		else
			set_bit(ZONE_BELOW_HIGH, &zone->flags);

// 省略部分主要是在检查水位线失败时的其他处理逻辑
check_alloc_wmark:
	......
try_this_zone:
    /* 关键的分配函数，尝试从当前zone区域的freelist中分配page。*/
		page = rmqueue(ac->preferred_zoneref->zone, zone, order,
				gfp_mask, alloc_flags, ac->migratetype);
	......
	return NULL;
}

进一步会调用到rmqueue_buddy->__rmqueue->__rmqueue_cma_fallback->__rmqueue_smallest执行页的获取。

/*
 * Go through the free lists for the given migratetype and remove
 * the smallest available page from the freelists
 */
static __always_inline
struct page *__rmqueue_smallest(struct zone *zone, unsigned int order,
						int migratetype)
{
	unsigned int current_order;
	struct free_area *area;
	struct page *page;

	/* Find a page of the appropriate size in the preferred list */
	for (current_order = order; current_order <= MAX_ORDER; ++current_order) { // 从请求order开始遍历free_area
		area = &(zone->free_area[current_order]);
		page = get_page_from_free_area(area, migratetype); // 从当前的伙伴系统里试着拿出一个free块
		if (!page)
			continue; // 没拿到的话就再找下一个大小的free_area
		del_page_from_free_list(page, zone, current_order); // 把当前的内存组从free list删除
		expand(zone, page, order, current_order, migratetype);// 如果找到的页面大于请求的order，将其拆分为更小的块
		set_pcppage_migratetype(page, migratetype); // 设置页面的迁移类型。
		trace_mm_page_alloc_zone_locked(page, order, migratetype,
				pcp_allowed_order(order) &&
				migratetype < MIGRATE_PCPTYPES);
		return page;
	}

	return NULL;
}

而当我们在更大的页框组拆分的时候，则会把多余的页框组插到其他free_area中，并把目标的order和current_order作对比。

static inline void expand(struct zone *zone, struct page *page,
	int low, int high, int migratetype)
{
	unsigned long size = 1 << high; // 要被拆分的页大小

	while (high > low) {
		high--; // 把current_order递减到实际的需求order
		size >> = 1;
		VM_BUG_ON_PAGE(bad_range(zone, &page[size]), &page[size]); // 按照当前的size把原始大小的页框组拆分

		/*
		 * Mark as guard pages (or page), that will allow to
		 * merge back to allocator when buddy will be freed.
		 * Corresponding page table entries will not be touched,
		 * pages will stay not present in virtual address space
		 */
		if (set_page_guard(zone, &page[size], high, migratetype))
			continue;

		add_to_free_list(&page[size], zone, high, migratetype); // 把拆分出来的直接加回到新的free list中
		set_buddy_order(&page[size], high);
	}
}

3.3-释放函数

当系统调用free_page的时候，伙伴系统会尝试把当前的页面还原给大的order组，这样的操作可以有效减少内存的碎片化。

static inline void __free_one_page(struct page *page,
		unsigned long pfn,
		struct zone *zone, unsigned int order,
		int migratetype, fpi_t fpi_flags)
{
	......
	VM_BUG_ON(!zone_is_initialized(zone)); // 确保传入的zone已经初始化
	VM_BUG_ON_PAGE(page->flags & PAGE_FLAGS_CHECK_AT_PREP, page);

	VM_BUG_ON(migratetype == -1);
	if (likely(!is_migrate_isolate(migratetype)))
		__mod_zone_freepage_state(zone, 1 << order, migratetype); // 检查migratetype是否为MIGRATE_ISOLATE

	VM_BUG_ON_PAGE(pfn & ((1 << order) - 1), page); // 确保传入的pfn与order匹配
	VM_BUG_ON_PAGE(bad_range(zone, page), page);

  /* 尝试寻找并合并当前页面的伙伴页面 */
	while (order < MAX_ORDER) { 
		......
		buddy = find_buddy_page_pfn(page, pfn, order, &buddy_pfn); // 查找当前页的buddy
		if (!buddy)
			goto done_merging;
		......
		/*
		 * Our buddy is free or it is CONFIG_DEBUG_PAGEALLOC guard page,
		 * merge with it and move up one order.
		 */
		if (page_is_guard(buddy)) // 查看是否找到了当前page的伙伴系统是否是守护页
			clear_page_guard(zone, buddy, order, migratetype); // 如果伙伴页面是守卫页，这一步会清除守卫页的状态，准备它们进行合并
		else
			del_page_from_free_list(buddy, zone, order); // 不是守卫页，将伙伴页面从free list中移除，以便将其与当前页面合并。
		combined_pfn = buddy_pfn & pfn;
		page = page + (combined_pfn - pfn);
		pfn = combined_pfn;
		order++;
	}

done_merging:
	set_buddy_order(page, order); // 设置合并后的页order

  /* 函数根据fpi_flags和其他条件决定将合并后的页添加到zone的free list的头部还是尾部 */
	if (fpi_flags & FPI_TO_TAIL)
		to_tail = true;
	else if (is_shuffle_order(order))
		to_tail = shuffle_pick_tail();
	else
		to_tail = buddy_merge_likely(pfn, buddy_pfn, page, order);

	if (to_tail)
		add_to_free_list_tail(page, zone, order, migratetype);
	else
		add_to_free_list(page, zone, order, migratetype);

	/* Notify page reporting subsystem of freed page */
	if (!(fpi_flags & FPI_SKIP_REPORT_NOTIFY))
		page_reporting_notify_free(order);
}

这里主要执行find_buddy_page_pfn查找合适的伙伴系统页面的原因

1. 合并内存块：

   当页面被释放时，系统尝试找到它的伙伴页面，以判断是否可以将这两个页面合并成一个更大的内存块。这种合并减少了内存碎片化，提高了内存利用率。

2. 维持伙伴系统的完整性：

   伙伴系统基于成对的页面块进行工作。每次分配或释放时，都必须维护这种配对关系，以确保系统的高效和一致性。

3. 优化内存分配：

   通过合并释放的页面和其伙伴页面，伙伴系统可以为未来的大块内存分配请求提供更多的连续内存，从而提高内存分配的效率。

static inline struct page *find_buddy_page_pfn(struct page *page,
			unsigned long pfn, unsigned int order, unsigned long *buddy_pfn)
{
	unsigned long __buddy_pfn = __find_buddy_pfn(pfn, order); // 查找当前order对应伙伴页面的页面帧号（PFN）
	struct page *buddy;

	buddy = page + (__buddy_pfn - pfn); // 通过计算得到的PFN定位伙伴页面
	if (buddy_pfn)
		*buddy_pfn = __buddy_pfn;

	if (page_is_buddy(page, buddy, order)) // 检查是否为有效伙伴页面
		return buddy;
	return NULL;
}