CPU知识学习汇总【转】
转自：https://www.cnblogs.com/hellokitty2/p/12898962.html
一、相关名词解释
SMP：(Symmetric Multi-Processing)对称多处理，一个chip上集成多个核心
SMT：(Simultaneous multithreading)同时多线程，一个核心上实现多个hardware context，以支持多线程。通过复制硬件寄存器状态等手段，同时执行多个线程。
Node：某些Core之间，独享总线和memory，称作Node。Core只访问Node内的memory，因此可以减轻对总线和memory的带宽需求。但是有些场景下，Core会不可避免的访问其它Node的memory，这会造成很大的访问延迟。
NUMA: (Non-uniform Memory Access)不一致内存访问，以内存访问的不一致性为代价，减轻对总线和memory的带宽需求。这种结构对进程调度算法的要求较高，尽量减少跨Node的内存访问次数，以提升系统性能。
HMP：(Heterogeneous Multi-Processing)异构多处理，ARM的一种架构，在乎功耗的存在。HMP架构在一个chip中，封装两类ARM Core，一类为高性能Core（如Cortex-A15，也称作big core），一类为低性能Core（如Cortex-A7，也称作little core），因此HMP也称作big·little架构。
还有big-middle-little架构。
二、CPU拓扑
1. CPU topology除了描述CPU的组成之外，其主要功能是向kernel调度器提供必要的信息，以便让它合理地分配任务，最终达到性能和功耗之间的平衡。
CPU topology：Cluster-->Core-->Threads
2.CPU拓扑框架
------------------------- ---------------------------- | CPU topology driver | | Task Scheduler etc. | ------------------------- ---------------------------- ------------------------------------------------------- | Kernel general CPU topology | ---------------------------------------------------------- ---------------------------------------------------------- | arch-dependent CPU topology | ----------------------------------------------------------
Kernel general CPU topology位于"include/linux/topology.h”中，定义了获取系统CPU topology信息的标准接口。底层的arch-dependent CPU topology会根据平台的特性，实现kernel定义的那些接口。
CPU topology信息有两个重要的使用场景：一是向用户提供当前的CPU信息（eg：lscpu），这是由CPU topology driver实现的；二是向调度器提供CPU core的信息，以便合理的调度任务。
2.1 Kernel general CPU topology
Kernel general CPU topology位于 include/linux/topology.h 中，主要以“#ifndef ... #define”类型的宏定义的形式提供API，其目的是：底层的arch-dependent CPU topology可以重新定义这些宏，只要底层有定义，则优先使用底层的，否则就使用Kernel general CPU topology中的默认API，主要包括：
/* include/linux/topology.h */
#ifndef topology_physical_package_id
#define topology_physical_package_id(cpu) ((void)(cpu), -1)
#endif
#ifndef topology_core_id
#define topology_core_id(cpu) ((void)(cpu), 0)
#endif
#ifndef topology_thread_cpumask
#define topology_thread_cpumask(cpu) cpumask_of(cpu)
#endif
#ifndef topology_core_cpumask
#define topology_core_cpumask(cpu) cpumask_of(cpu)
#endif
#ifdef CONFIG_SCHED_SMT
static inline const struct cpumask *cpu_smt_mask(int cpu)
{
return topology_thread_cpumask(cpu);
}
#endif
static inline const struct cpumask *cpu_cpu_mask(int cpu)
{
return cpumask_of_node(cpu_to_node(cpu));
}
topology_physical_package_id：用于获取某个CPU的package ID，即socket(X86)或者cluster(ARM)，具体意义依赖于具体平台的实现；
topology_core_id：某个CPU的core ID。即第二章所描述的core，具体意义依赖于具体的平台实现；
topology_thread_cpumask：获取和该CPU属于同一个core的所有CPU，通俗的讲，就是姐妹Thread；
topology_core_cpumask：获取和该CPU属于同一个cluster的所有CPU；
cpu_cpu_mask: 获取该CPU属于同一个Node的所有CPU；
cpu_smt_mask: 用于SMT调度（CONFIG_SCHED_SMT）的一个封装，意义同topology_thread_cpumask。
2.2 arch-dependent CPU topology
位于“arch/arm64/include/asm/topology.h”和“arch/arm64/kernel/topology.c”中，主要负责ARM64平台相关的topology转换，包括：
(1) 定义一个数据结构，以及基于该数据结构的变量，用于存储系统的CPU topology
/* arch/arm64/include/asm/topology.h */
struct cpu_topology {
int thread_id;
int core_id;
int cluster_id;
cpumask_t thread_sibling;
cpumask_t core_sibling;
};
extern struct cpu_topology cpu_topology[NR_CPUS];
cluster_id、core_id、thead_id描述了拓扑结构的三个层次，thread_sibling和core_sibling，保存了和该CPU位于相同级别（同一个core和同一个cluster）的所有姐妹CPU。系统中每个CPU（个数由NR_CPUS指定，是从OS的角度看的）都有一个struct cpu_topology变量，用于描述该CPU在整个topology中的地位。以数组的形式维护。
(2)重定义CPU topology有关的宏定义
/* arch/arm64/include/asm/topology.h */ #define topology_physical_package_id(cpu) (cpu_topology[cpu].cluster_id) #define topology_core_id(cpu) (cpu_topology[cpu].core_id) #define topology_core_cpumask(cpu) (&cpu_topology[cpu].core_sibling) #define topology_thread_cpumask(cpu) (&cpu_topology[cpu].thread_sibling)
实现比较简单，从该CPU对应的struct cpu_topology变量中取出指定的字段即可。
(3)提供初始化并构建CPU topology的方法，以便在系统启动时调用
/* arch/arm64/include/asm/topology.h */ void init_cpu_topology(void); void store_cpu_topology(unsigned int cpuid);
init_cpu_topology的调用路径是：kernel_init-->smp_prepare_cpus-->init_cpu_topology，主要完成如下任务：
store_cpu_topology的调用路径是：kernel_init-->smp_prepare_cpus-->store_cpu_topology，在没有从DTS中成功获取CPU topology的情况下，从ARM64的MPIDR寄存器中读取topology信息。
设备树中的cpu-map和clusterX描述了CPU的拓扑结构，具体可参考“Documentation/devicetree/bindings/arm/topology.txt”中的描述。
2.3 CPU topology driver
CPU topology driver位于“drivers\base\topology.c”中，基于“include/linux/topology.h”所提供的API，以sysfs的形式，向用户空间提供获取CPU topology信息的接口，lscpu应用，就是基于该接口实现的。sysfs的格式可参考“Documentation/cputopology.txt”。
/sys/devices/system/cpu/cpuX/topology/下
physical_package_id: //就是此CPU位于的Cluster编号 core_id: //在一个Cluster内此CPU的编号 thread_siblings: //每个CPU核的位掩码，CPU0 CPU1 CPU2分别为0x1 0x2 0x4 thread_siblings_list: //CPU是几这个就是几，CPU0就是0，CPU7就是7 core_siblings: //每个Cluster内的CPU组成的位掩码，若四小核Cluster0就是0x0f，3中核就是0x70 core_siblings_list: //每个Cluster内的CPU组成的数字加中画线显示，若4小核，3中核，1大核，小核的是0-3，中核就是4-6，大核就是7
/sys/devices/system/cpu/下
kernel_max 一共有多少个核，7 kernel_max: 31 offline: 2,4-31,32-63 online: 0-1,3 possible: 0-31 present: 0-31
3. CPU一共有4种状态需要表示：
cpu_possible_bits，系统中包含的所有的可能的CPU core，在系统初始化的时候就已经确定。对于ARM64来说，DTS中所有格式正确的CPU core，都属于possible的core； cpu_present_bits，系统中所有可用的CPU core（具备online的条件，具体由底层代码决定），并不是所有possible的core都是present的。对于支持CPU hotplug的形态，present core可以动态改变； cpu_online_bits，系统中所有运行状态的CPU core（后面会详细说明这个状态的意义）； cpu_active_bits，有active的进程正在运行的CPU core。
三、Linux cpu ops
1. 在SMP系统中，Linux kernel会在一个CPU（primary CPU）上完成启动操作。primary CPU启动完成后，再启动其它的CPU（secondary CPUs），这称作secondary CPU boot。一般是CPU0作为boot cpu。
2. CPU（或SOC）中会集成一个ROM，ROM上有CPU厂商在出厂时固化的代码，这些代码会进行一些必要的初始化后，将CPU跳转到其它地址（例如0x20000000），这些地址一般是RAM或者NOR flash，用户代
码可以存放在这些位置。
3. 不同的CPU core可能有着不同的power domain，因而有可能单独上电。
4. CPU hotplug
hotplug功能，是在处理性能需求不高的情况下，从物理上关闭不需要的CPU core，并在需要的时候，将它们切换为online状态的一种手段。和cpuidle类似，cpu hotplug也是根据系统负荷，动态调整
处理器性能，从而达到节省功耗的目的。
hotplug与idle的区别：
处于idle状态的CPU，对调度器来说是可见的，换句话说，调度器并不知道某个CPU是否处于idle状态，因此不需要对它们做特殊处理。而处于un-hotplugged状态CPU，对调度器是不可见，因此调度器必
须做一些额外的处理，包括：主动移除CPU，并将该CPU上的中断等资源迁移到其它CPU上，同时进行必要的负载均衡；反之亦然。
5. 每一个core掉电后，都要检查该core的sibling core是否都已掉电，如果是，则关闭cluster的供电。
6. cpu ops
对ARM64平台来说，kernel使用struct cpu_operations来抽象cpu ops
struct cpu_operations {
const char *name;
int (*cpu_init)(struct device_node *, unsigned int);
int (*cpu_init_idle)(struct device_node *, unsigned int);
int (*cpu_prepare)(unsigned int);
int (*cpu_boot)(unsigned int);
void (*cpu_postboot)(void);
#ifdef CONFIG_HOTPLUG_CPU
int (*cpu_disable)(unsigned int cpu);
void (*cpu_die)(unsigned int cpu);
int (*cpu_kill)(unsigned int cpu);
#endif
#ifdef CONFIG_ARM64_CPU_SUSPEND
int (*cpu_suspend)(unsigned long);
#endif
};
针对ARM64，kernel提供了两种可选的方法，smp spin table和psci，如下：
static const struct cpu_operations *supported_cpu_ops[] __initconst = {
#ifdef CONFIG_SMP
&smp_spin_table_ops,
#endif
&cpu_psci_ops,
NULL,
};
具体使用哪一个operation，是通过DTS中的“enable-method”域指定的，DTS格式如下：
cpus {
...
cpu@000 {
...
enable-method = "psci";
cpu-release-addr = <0x1 0x0000fff8>;
};
...
};
系统初始化的时候，会根据DTS配置获取使用的operations（setup_arch-->cpu_read_bootcpu_ops-->cpu_read_ops），最终保存在一个cpu_ops数组(每个CPU一个)中，供SMP（arch/arm64/kernel/smp.c）使用，如下：
/* arch/arm64/kernel/cpu_ops.c */ const struct cpu_operations *cpu_ops[NR_CPUS];
三、cpu control & hotplug
1. kernel cpu control位于“./kernel/cpu.c”中，是一个承上启下的模块，负责屏蔽arch-dependent的实现细节，向上层软件提供控制CPU core的统一API（主要包括cpu_up/cpu_down等接口的实现）。
2. cpu的四种状态
kernel使用4个bitmap，来保存分别处于4种状态的CPU core：possible、present、active和online。
/* include/linux/cpumask.h */ cpu_possible_mask- has bit 'cpu' set iff cpu is populatable，在启动时就是固定的，作为CPU ID的集合，可理解为存在这个CPU资源。 cpu_present_mask - has bit 'cpu' set iff cpu is populated，cpu_present_mask是动态的，表示当前插入了哪些CPU，可理解为被kernel接管。 cpu_online_mask - has bit 'cpu' set iff cpu available to scheduler，pu_online_mask是cpu_present_mask的动态子集，指示可用于调度的CPU。 cpu_active_mask - has bit 'cpu' set iff cpu available to migration，即是否对调度器可见
如果启用了HOTPLUG，则将强制cpu_possible_mask设置为所有NR_CPUS位。
2.1 possible CPU
possible的CPUs，代表了系统中可被使用的所有的CPU，在boot阶段确定之后，就不会再修改。以ARM64为例，其初始化的过程如下：
(1)系统上电后，boot CPU启动，执行start_kernel（init/main.c），并分别调用 boot_cpu_init 和 setup_arch 两个接口，进行possible CPU相关的初始化。
(2)boot_cpu_init负责将当前的boot CPU放到possible CPU的bitmap中，同理，boot CPU也是present、oneline、active CPU。
/* init/main.c */
static void __init boot_cpu_init(void)
{
int cpu = smp_processor_id(); //用户获取当前CPU的ID
/* Mark the boot cpu "present", "online" etc for SMP and UP case */
set_cpu_online(cpu, true);
set_cpu_active(cpu, true);
set_cpu_present(cpu, true);
set_cpu_possible(cpu, true);
}
2.2 present CPU
start_kernel —> rest_init —> kernel_init（pid 1，init task） —> kernel_init_freeable -> smp_prepare_cpus”，轮询所有的possible CPU，如果某个CPU core满足具备相应的cpu_ops指针，cpu ops的.cpu_prepare回调成功，则调用set_cpu_present()，将其设置为present CPU。
2.3 online CPU
已经boot的CPU，会在 secondary_start_kernel 中，调用 set_cpu_online 接口，将其设置为online状态。反之，会在__cpu_disable中将其从online mask中清除。
2.4 active CPU
调度器需要监视 CPU hotplug 有关的每一个风吹草动。由于调度器和CPU控制两个独立的模块，kernel 通过 notifier 机制实现这一功能。每当系统的CPU资源有任何变动，kernel CPU control 模块就会通知调度器，调度器根据相应的event（CPU_DOWN_FAILED、CPU_DOWN_PREPARE等），调用set_cpu_active接口，将某个CPU添加到active mask或者移出active mask。这就是active CPU的意义。
3. 对于支持CPU hotplug功能的平台来说，可以在系统启动后的任意时刻，关闭任意一个secondary CPU（对ARM平台来说，CPU0或者说boot CPU，是不可以被关闭的），并在需要的时候，再次打开它。
4. 在kernel/cpu.c中，cpu_up 接口，只会在使能了 CONFIG_SMP 配置项（意味着是SMP系统）后才会提供。而cpu_down接口，则只会在使能了 CONFIG_HOTPLUG_CPU 配置项后才会提供。
5. per-CPU 的idle线程
boot CPU在执行初始化动作的时候，会通过“smp_init —> idle_threads_init —> idle_init”的调用，为每个CPU创建一个idle线程，如下：
/* kernel/smpboot.c */
static inline void idle_init(unsigned int cpu)
{
struct task_struct *tsk = per_cpu(idle_threads, cpu);
if (!tsk) {
tsk = fork_idle(cpu);
if (IS_ERR(tsk))
pr_err("SMP: fork_idle() failed for CPU %u\n", cpu);
else
per_cpu(idle_threads, cpu) = tsk;
}
}
该接口的本质是，为每个CPU fork一个idle thread（由struct task_struct结构表示），并保存在一个per-CPU的全局变量（idle_threads）中。此时，idle thread只是一个task结构，并没有执行。
6. 打开和关闭CPU分析
在当前kernel实现中，只支持通过sysfs的形式，关闭或打开CPU：
echo 0 > /sys/devices/system/cpu/cpuX/online # 关闭CPU echo 1 > /sys/devices/system/cpu/cpuX/online # 打开CPU
CPU online 的软件流程如下：
echo 0 > /sys/devices/system/cpu/cpuX/online
online_store(drivers/base/core.c)
device_online(drivers/base/core.c)
cpu_subsys_online(drivers/base/cpu.c)
cpu_up(kernel/cpu.c)
_cpu_up(kernel/cpu.c)
(1) up前后，发送PREPARE、ONLINE、STARTING等notify，以便让关心者作出相应的动作，例如调度器、RCU、workqueue等模块，都需要关注CPU的hotplug动作，以便进行任务的重新分配等操作。
(2) 执行Arch-specific相关的boot操作，将CPU boot起来，最终通过 secondary_start_kernel 接口，停留在per-CPU的idle线程上。
_cpu_up 接口会在完成一些准备动作之后，调用平台相关的__cpu_up接口，由平台代码完成具体的up操作，如下：
static int _cpu_up(unsigned int cpu, int tasks_frozen)
{
void *hcpu = (void *)(long)cpu;
unsigned long mod = tasks_frozen ? CPU_TASKS_FROZEN : 0;
struct task_struct *idle;
cpu_hotplug_begin();
idle = idle_thread_get(cpu);
ret = smpboot_create_threads(cpu);
ret = __cpu_notify(CPU_UP_PREPARE | mod, hcpu, -1, &nr_calls);
ret = __cpu_up(cpu, idle);
/* Wake the per cpu threads */
smpboot_unpark_threads(cpu);
/* Now call notifier in preparation. */
cpu_notify(CPU_ONLINE | mod, hcpu);
}
准备动作包括：
(1) 获取idle thread的task指针，该指针最终会以参数的形式传递给arch-specific代码。
(2) 创建一个用于管理CPU hotplug动作的线程（smpboot_create_threads），该线程的具体意义，后面会再说明。
(3) 发送CPU_UP_PREPARE notify。
以ARM64为例，__cpu_up 的内部实现如下：
/* arch/arm64/kernel/smp.c */
int __cpu_up(unsigned int cpu, struct task_struct *idle)
{
int ret;
/* We need to tell the secondary core where to find its stack and the page tables. */
secondary_data.stack = task_stack_page(idle) + THREAD_START_SP;
__flush_dcache_area(&secondary_data, sizeof(secondary_data));
/* Now bring the CPU into our world. */
ret = boot_secondary(cpu, idle);
if (ret == 0) {
/*
* CPU was successfully started, wait for it to come online or
* time out.
*/
wait_for_completion_timeout(&cpu_running, msecs_to_jiffies(1000));
cpu_online(cpu);
} else {
pr_err("CPU%u: failed to boot: %d\n", cpu, ret);
}
secondary_data.stack = NULL;
return ret;
}
该接口以 idle thread 的 task 指针为参数，完成如下动作：
(1) 将idle线程的堆栈，保存在一个名称为 secondary_data 的全局变量中（这地方很重要，后面再介绍其中的奥妙）。
(2) 执行 boot_secondary 接口，boot CPU，具体的流程。
(3) boot_secondary 返回后，等待对应的CPU切换为online状态。
secondary_startup 接口位于arch/arm64/kernel/head.S中，负责secondary CPU启动后的后期操作，如下：
ENTRY(secondary_startup)
/*
* Common entry point for secondary CPUs.
*/
mrs x22, midr_el1 // x22=cpuid
mov x0, x22
bl lookup_processor_type
mov x23, x0 // x23=current cpu_table
cbz x23, __error_p // invalid processor (x23=0)?
pgtbl x25, x26, x28 // x25=TTBR0, x26=TTBR1
ldr x12, [x23, #CPU_INFO_SETUP]
add x12, x12, x28 // __virt_to_phys
blr x12 // initialise processor
ldr x21, =secondary_data
ldr x27, =__secondary_switched // address to jump to after enabling the MMU
b __enable_mmu
ENDPROC(secondary_startup)
ENTRY(__secondary_switched)
ldr x0, [x21] // get secondary_data.stack
mov sp, x0
mov x29, #0
b secondary_start_kernel
ENDPROC(__secondary_switched)
我们重点关注上面16~17行，以及21~26行的 __secondary_switched，__secondary_switched 会将保存在 secondary_data 全局变量中的堆栈取出，保存在该CPU的SP中，
并跳转到 secondary_start_kernel 继续执行。
CPU启动后，需要先配置好堆栈，才能进行后续的函数调用，这里使用的是该CPU idle thread的堆栈。看一下kernel中“current”指针（获取当前task结构的宏定义）的实现方法：
#define current get_current()
#define get_current() (current_thread_info()->task)
static inline struct thread_info *current_thread_info(void)
{
register unsigned long sp asm ("sp");
return (struct thread_info *)(sp & ~(THREAD_SIZE - 1));
}
通过CPU的SP指针，是可以获得CPU的当前task的。也就是说，当CPU SP被赋值为idle thread的堆栈的那一瞬间，当前的上下文已经是idle thread了！
6. 另外，CPU hotplug 还受“maxcpus”命令行参数影响
系统启动的时候，可以通过命令行参数“maxcpus”，告知kernel本次启动所使用的CPU个数，该个数可以小于等于possible CPU的个数。系统初始化时，只会把“maxcpus”所指定个数的CPU置为present状态
Documentation\cpu-hotplug.txt”文档是这样描述的：
maxcpus=n Restrict boot time cpus to n. Say if you have 4 cpus, using
maxcpus=2 will only boot 2. You can choose to bring the
other cpus later online, read FAQ's for more info.
注：
内核中经常有这样的函数，xxx、_xxx 或者 __xxx，区别是一个或者两个下划线，其中的含义是：
xxx接口，通常需要由某个锁保护，一般提供给其它模块调用。它会直接调用_xxx接口；
_xxx接口，则不需要保护，一般由模块内部在确保安全的情况下调用。有时，外部模块确信可行（不需要保护），也可能会直接调用；
__xxx接口，一般提供给arch-dependent的软件层实现，比如这里的arch/arm64/kernel/xxx.c。
理解这些含义后，会加快我们阅读代码的速度，另外，如果直接写代码，也尽量遵守这样的原则，以便使自己的代码更规范、更通用。
参考：
Linux CPU core的电源管理(1)_概述: http://www.wowotech.net/pm_subsystem/cpu_core_pm_overview.html
Linux CPU core的电源管理(2)_cpu topology：http://www.wowotech.net/pm_subsystem/cpu_topology.html
Linux CPU core的电源管理(5)_cpu control及cpu hotplug：http://www.wowotech.net/pm_subsystem/cpu_hotplug.html
