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。

mc_support


前面讲过,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上,以满足性能和功耗的平衡。

HMP

在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

Logo

更多推荐