cpu 拓补结构

1. 前言

在“Linux CPU core的电源管理(1)_概述”中，我们多次提到SMP、CPU core等概念，虽然硬着头皮写下去了，但是蜗蜗对这些概念总有些似懂非懂的感觉。它们和CPU的进化过程息息相关，最终会体现在CPU topology（拓扑结构）上。因此本文将以CPU topology为主线，介绍CPU有关（主要以ARM CPU为例）的知识。

另外，CPU topology除了描述CPU的组成之外，其主要功能，是向kernel调度器提供必要的信息，以便让它合理地分配任务，最终达到性能和功耗之间的平衡。这也是我将“cpu topology”归类为“电源管理子系统”的原因。

2. CPU topology

2.1 一个例子

开始之前，先看一个例子，下面是蜗蜗所使用的编译服务器的CPU architecture信息：

[xxx@cs ~]# lscpu

Architecture:          x86_64 
CPU op-mode(s):        32-bit, 64-bit 
Byte Order:            Little Endian 
CPU(s):                24 
On-line CPU(s) list:   0-23 
Thread(s) per core:    2 
Core(s) per socket:    6 
Socket(s):             2 
NUMA node(s):          2 
Vendor ID:             GenuineIntel 
CPU family:            6 
Model:                 62 
Stepping:              4 
CPU MHz:               2100.118 
BogoMIPS:              4199.92 
Virtualization:        VT-x 
L1d cache:             32K 
L1i cache:             32K 
L2 cache:              256K 
L3 cache:              15360K 
NUMA node0 CPU(s):     0,2,4,6,8,10,12,14,16,18,20,22 
NUMA node1 CPU(s):     1,3,5,7,9,11,13,15,17,19,21,23

注意其中蓝色字体部分，该服务器有24个CPU，组成方式是：2个sockets，每个socket有6个core，每个core有2个thread。另外，这些CPU可以划分为2个NUMA node。晕吧，知道我在说什么吗？不知道就对了，让我做进一步的解释。

2.2 单核和多核

在英文里面，单核（single-core）和多核（multi-core）多称作uniprocessor和multiprocessor，这里先对这些概念做一个说明：

这里所说的core（或processor），是一个泛指，是从使用者（或消费者）的角度看计算机系统。因此，core，或者processor，或者处理器（CPU），都是逻辑概念，指的是一个可以独立运算、处理的核心。

而这个核心，可以以任何形式存在，例如：单独的一个chip（如通常意义上的单核处理器）；一个chip上集成多个核心（如SMP，symmetric multiprocessing）；一个核心上实现多个hardware context，以支持多线程（如SMT，Simultaneous multithreading）；等等。这是从硬件实现的角度看的。

最后，从操作系统进程调度的角度，又会统一看待这些不同硬件实现的核心，例如2.1中所提及的CPU（24个CPUs），因为它们都有一个共同的特点：执行进程（或线程）。

在传统的单核时代，提升处理器性能的唯一手段就是提高频率。但受限于物理工艺，频率不能无限提高（例如散热问题等）。对多核处理器来说，可利用的空间增多，散热问题就比较容易解决。这就是multiprocessor诞生的背景。

另外，现实中的多任务需求，也是multiprocessor得以发展的基础，例如智能手机中，可以使用一个processor处理通信协议，另一个processor处理UI交互、多媒体等，这可以让用户在享受“智能”的同时，确保不miss基础的通信需求。

2.3 SMP、SMT、NUMA等概念

比较常见的multiprocessor实现，是将多个功能完全相同的processor集成在一起（可以在一个chip上，也可以在多个chip），它们共享总线、memory等系统资源，这称作SMP（Symmetric Multi-Processing），如下面图片中的CORE000、CORE001…。从Linux kernel的角度，通常称这些功能独立的process为Core。

另外，基于制程、扩充性等考虑，芯片厂商会把多个Core封装在一个chip上，这也称作Socket。Socket的概念在X86架构上使用尤其多，可以理解为插槽。假设一个插槽有两个Core，那么我在主板上插2个插槽，就是4核系统，插4个插槽，就是8核系统。不过Socket在ARM体系结构上使用却比较少，后面我们会介绍另外一个类似概念（Cluster）。

大多数操作系统（如Windows、Linux），有进程和线程的概念。进程是程序的运行实例，可以包括很多线程。线程是调度的最小单位。因此有些处理器（Core），可以通过复制硬件寄存器状态等手段，同时执行多个线程，这叫做SMT（Simultanous Multi-Thread）。

下面图片以及2.1中的例子，反映了多核系统的简单topology。

前面讲过，Core之间会共享总线、memory等资源。如果Core的数量较少，则没什么问题，但随着Core的增多，对总线以及memory带宽的需求就会显著增大，最终总线和memory会成为系统性能的瓶颈。解决方法是：

某些Core之间，独享总线和memory，称作Node。正常情况下，Core只访问Node内的memory，因此可以减轻对总线和memory的带宽需求。但是，有些场景下，Core会不可避免的访问其它Node的memory，这会造成很大的访问延迟。

因此，这种技术称作NUMA（Non-uniform Memory Access），以内存访问的不一致性为代价，减轻对总线和memory的带宽需求。这种结构对进程调度算法的要求较高，尽量减少跨Node的内存访问次数，以提升系统性能。

2.4 ARM HMP（Heterogeneous Multi-Processing）

前面提到的拓扑结构，大多存在于X86架构的PC、服务器上，唯一目标就是提升CPU的处理性能（不在乎功耗）。但在移动市场（大多是ARM的天下），事情就复杂多了。

随着智能设备的普及，用户对移动设备的性能需求越来越高，相应的就更多有的power消耗，这对设备的电源管理以及散热处理提出了更高的要求。与此同时，电池技术却没有随着CPU拓扑结构的进化而进化，这就导致上述的拓扑结构不太适合对功耗特别敏感的移动设备，这就是ARM的HMP技术提出的背景。

Heterogeneous的中文意思是“异形的、多种多样的”，从字面意思理解，就是其内部的多个Core有着不同的实现（相对于SMP）。它的产生基于下面两个事实：

1）在处理同等事务的情况下，处理器的性能越高，其能量损耗就越大。这是由物理工艺决定的。

2）以智能手机为例，必须由高性能CPU来完成的事务，在所有事物里的比重是非常小的，如大型游戏、高清视频播放等。甚至很多用户从来都没有用过。

因此，ARM提出类似下面架构的HMP架构，在一个chip中，封装两类ARM Core，一类为高性能Core（如Cortex-A15，也称作big core），一类为低性能Core（如Cortex-A7，也称作little core），因此HMP也称作big·little架构。其中：

big core的处理性能高，但功耗较大；

little core的功耗低；

因此软件（如OS的调度器）可以根据需求，将任务分配到big core或者little上，以满足性能和功耗的平衡。

在ARM的术语中，所有big core或者所有little core组合，称作cluster（可以类比为2.3中所描述的Socket，但意义完全不同），因此在多数的ARM处理器中（不排除后续ARM服务器又不同实现），CPU topology如下：

Cluster-->Core-->Threads

在软件模型上，基本和2.3中描述的“Socket—>Core-->Threads”拓扑兼容。

3. Linux kernel CPU topology driver

弄明白CPU topology的物理基础之后，再来看Linux kernel的CPU topology driver就简单多了，其软件层次如下：

---------------------------------------------     --------------------------------------------  
|       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信息（2.1中的lscpu），这是由CPU topology driver实现的；二是向调度器提供CPU core的信息，以便合理的调度任务。

下面将重点介绍Kernel general CPU topology、arch-dependent CPU topology和CPU topology driver，其中arch-dependent CPU topology会以ARM64平台为例。至于如何知道任务调度，则比较复杂，会放到其它文章中介绍。

3.1 Kernel general CPU topology

Kernel general CPU topology主要以“#ifndef ... #define”类型的宏定义的形式提供API，其目的是：底层的arch-dependent CPU topology可以重新定义这些宏，只要底层有定义，则优先使用底层的，否则就使用Kernel general CPU topology中的默认API，主要包括：

   1: /* include/linux/topology.h */

   2:  

   3: #ifndef topology_physical_package_id

   4: #define topology_physical_package_id(cpu)       ((void)(cpu), -1)

   5: #endif

   6: #ifndef topology_core_id

   7: #define topology_core_id(cpu)                   ((void)(cpu), 0)

   8: #endif

   9: #ifndef topology_thread_cpumask

  10: #define topology_thread_cpumask(cpu)            cpumask_of(cpu)

  11: #endif

  12: #ifndef topology_core_cpumask

  13: #define topology_core_cpumask(cpu)              cpumask_of(cpu)

  14: #endif

  15:  

  16: #ifdef CONFIG_SCHED_SMT

  17: static inline const struct cpumask *cpu_smt_mask(int cpu)

  18: {

  19:         return topology_thread_cpumask(cpu);

  20: }

  21: #endif

  22:  

  23: static inline const struct cpumask *cpu_cpu_mask(int cpu)

  24: {

  25:         return cpumask_of_node(cpu_to_node(cpu));

  26: }

topology_physical_package_id用于获取某个CPU的package ID，即第2章所描述的socket或者cluster，具体意义依赖于具体平台的实现；

topology_core_id用于或者某个CPU的core ID。即第二章所描述的core，具体意义依赖于具体的平台实现；

topology_thread_cpumask，获取和该CPU属于同一个core的所有CPU，通俗的讲，就是姐妹Thread；

topology_core_cpumask，获取和该CPU属于同一个packet（socket）的所有CPU；

cpu_cpu_mask，获取该CPU属于同一个Node的所有CPU；

cpu_smt_mask，用于SMT调度（CONFIG_SCHED_SMT）的一个封装，意义同topology_thread_cpumask。

另外，"include/linux/topology.h”提供一个NUMA有关的API，由于当前ARM使用NUMA技术的可能性不大，我们暂不过多涉及。

3.2 arch-dependent CPU topology

对ARM64而言，arch-dependent CPU topology位于“arch/arm64/include/asm/topology.h”和“arch/arm64/kernel/topology.c”中，主要负责ARM64平台相关的topology转换，包括：

1）定义一个数据结构，以及基于该数据结构的变量，用于存储系统的CPU topology

   1: /* arch/arm64/include/asm/topology.h */

   2:  

   3: struct cpu_topology {

   4:         int thread_id;

   5:         int core_id;

   6:         int cluster_id;

   7:         cpumask_t thread_sibling;

   8:         cpumask_t core_sibling;

   9: };

  10:  

  11: extern struct cpu_topology cpu_topology[NR_CPUS];

cluster_id、core_id、thead_id分别对应2.3、2.4章节所描述的拓扑结构的三个层次，其中由于ARM架构的特殊性，以cluster代替了socket；

thread_sibling和core_sibling为cpumask_t类型的变量，保存了和该CPU位于相同级别（同一个core和同一个cluster）的所有姐妹CPU；

系统中每个CPU（个数由NR_CPUS指定，是从OS的角度看的），都有一个struct cpu_topology变量，用于描述该CPU在整个topology中的地位。这些变量以数组的形式（cpu_topology）维护。

2）重定义CPU topology有关的宏定义

   1: /* arch/arm64/include/asm/topology.h */

   2:  

   3: #define topology_physical_package_id(cpu)       (cpu_topology[cpu].cluster_id)

   4: #define topology_core_id(cpu)           (cpu_topology[cpu].core_id)

   5: #define topology_core_cpumask(cpu)      (&cpu_topology[cpu].core_sibling)

   6: #define topology_thread_cpumask(cpu)    (&cpu_topology[cpu].thread_sibling)

实现比较简单，从该CPU对应的struct cpu_topology变量中取出指定的字段即可。

3）提供初始化并构建CPU topology的方法，以便在系统启动时调用

   1: /* arch/arm64/include/asm/topology.h */

   2:  

   3: void init_cpu_topology(void);

   4: void store_cpu_topology(unsigned int cpuid);

init_cpu_topology的调用路径是：kernel_init-->smp_prepare_cpus-->init_cpu_topology，主要完成如下任务：

初始化所有可能的CPU的struct cpu_topology变量;

尝试从DTS中解析CPU topolog配置，配置的格式如下：

cpus { 
        cpu-map {  
                cluster0 { 
                        core0 { 
                                thread0 { 
                                        cpu = <&big0>; 
                                }； 
                                thread1 { 
                                        cpu = <&big1>; 
                                }； 
                        }; 
                        core1 { 
                                … 
                        } 
                        … 
                }; 
               … 
        };

        big0: cpu@0 { 
                device_type = "cpu"; 
                compatible = "arm,cortex-a15"; 
                reg = <0x0>; 
        }; 
        … 
};

具体可参考“Documentation/devicetree/bindings/arm/topology.txt”中的描述。

store_cpu_topology的调用路径是：kernel_init-->smp_prepare_cpus-->store_cpu_topology，在没有从DTS中成功获取CPU topology的情况下，从ARM64的MPIDR寄存器中读取topology信息，具体可参考相应的代码，不再详细描述。

3.3 CPU topology driver

CPU topology driver位于“drivers\base\topology.c”中，基于“include/linux/topology.h”所提供的API，以sysfs的形式，向用户空间提供获取CPU topology信息的接口，lscpu应用，就是基于该接口实现的。

具体的实现比较简单，sysfs的格式可参考“Documentation\cputopology.txt”，这里不再详细说明。

转载： http://www.wowotech.net/pm_subsystem/cpu_topology.html