Category: Linux | 猿大白

Linux探秘之用户态与内核态

2018-07-06

Linux

文章首发于我的公众号「Linux云计算网络」，欢迎关注，第一时间掌握技术干货！

Unix/Linux的体系架构

如下图所示，从宏观上来看，Linux 操作系统的体系架构分为用户态和内核态（或者用户空间和内核）。

内核从本质上看是一种软件——控制计算机的硬件资源，并提供上层应用程序运行的环境。用户态即上层应用程序的活动空间，应用程序的执行必须依托于内核提供的资源，包括 CPU 资源、存储资源、I/O 资源等。为了使上层应用能够访问到这些资源，内核必须为上层应用提供访问的接口：即系统调用。

系统调用是操作系统的最小功能单位，这些系统调用根据不同的应用场景可以进行扩展和裁剪，现在各种版本的 Unix 实现都提供了不同数量的系统调用，如 Linux 的不同版本提供了 240-260 个系统调用，FreeBSD 大约提供了 320 个（reference：UNIX 环境高级编程）。

我们可以把系统调用看成是一种不能再化简的操作（类似于原子操作，但是不同概念），有人把它比作一个汉字的一个“笔画”，而一个“汉字”就代表一个上层应用，我觉得这个比喻非常贴切。因此，有时候如果要实现一个完整的汉字（给某个变量分配内存空间），就必须调用很多的系统调用。如果从实现者（程序员）的角度来看，这势必会加重程序员的负担，良好的程序设计方法是：重视上层的业务逻辑操作，而尽可能避免底层复杂的实现细节。

库函数正是为了将程序员从复杂的细节中解脱出来而提出的一种有效方法。它实现对系统调用的封装，将简单的业务逻辑接口呈现给用户，方便用户调用，从这个角度上看，库函数就像是组成汉字的“偏旁”。这样的一种组成方式极大增强了程序设计的灵活性，对于简单的操作，我们可以直接调用系统调用来访问资源，如“人”，对于复杂操作，我们借助于库函数来实现，如“仁”。显然，这样的库函数依据不同的标准也可以有不同的实现版本，如ISO C 标准库，POSIX 标准库等。

Shell 是一个特殊的应用程序，俗称命令行，本质上是一个命令解释器，它下通系统调用，上通各种应用，通常充当着一种“胶水”的角色，来连接各个小功能程序，让不同程序能够以一个清晰的接口协同工作，从而增强各个程序的功能。

同时，Shell 是可编程的，它可以执行符合 Shell 语法的文本，这样的文本称为 Shell 脚本，通常短短的几行 Shell 脚本就可以实现一个非常大的功能，原因就是这些 Shell 语句通常都对系统调用做了一层封装。为了方便用户和系统交互，一般，一个 Shell 对应一个终端，终端是一个硬件设备，呈现给用户的是一个图形化窗口。我们可以通过这个窗口输入或者输出文本。这个文本直接传递给 Shell 进行分析解释，然后执行。

总结一下，用户态的应用程序可以通过三种方式来访问内核态的资源：

系统调用
库函数
Shell 脚本

下图是对上图的一个细分结构，从这个图上可以更进一步对内核所做的事有一个“全景式”的印象。主要表现为：向下控制硬件资源，向内管理操作系统资源：包括进程的调度和管理、内存的管理、文件系统的管理、设备驱动程序的管理以及网络资源的管理，向上则向应用程序提供系统调用的接口。

从整体上来看，整个操作系统分为两层：用户态和内核态，这种分层的架构极大地提高了资源管理的可扩展性和灵活性，而且方便用户对资源的调用和集中式的管理，带来一定的安全性。

用户态和内核态的切换

因为操作系统的资源是有限的，如果访问资源的操作过多，必然会消耗过多的资源，而且如果不对这些操作加以区分，很可能造成资源访问的冲突。

所以，为了减少有限资源的访问和使用冲突，Unix/Linux 的设计哲学之一就是：对不同的操作赋予不同的执行等级，就是所谓特权的概念。简单说就是有多大能力做多大的事，与系统相关的一些特别关键的操作必须由最高特权的程序来完成。Intel 的 X86 架构的 CPU 提供了 0 到 3 四个特权级，数字越小，特权越高。

Linux 操作系统中主要采用了 0 和 3 两个特权级，分别对应的就是内核态和用户态。运行于用户态的进程可以执行的操作和访问的资源都会受到极大的限制，而运行在内核态的进程则可以执行任何操作并且在资源的使用上没有限制。

很多程序开始时运行于用户态，但在执行的过程中，一些操作需要在内核权限下才能执行，这就涉及到一个从用户态切换到内核态的过程。比如C函数库中的内存分配函数 malloc()，它具体是使用 sbrk() 系统调用来分配内存，当malloc() 调用 sbrk() 的时候就涉及一次从用户态到内核态的切换，类似的函数还有 printf()，调用的是 wirte() 系统调用来输出字符串，等等。

那到底在什么情况下会发生从用户态到内核态的切换，一般存在以下三种情况：

当然就是系统调用：原因如上的分析。
异常事件：当 CPU 正在执行运行在用户态的程序时，突然发生某些预先不可知的异常事件，这个时候就会触发从当前用户态执行的进程转向内核态执行相关的异常事件，典型的如缺页异常。
外围设备的中断：当外围设备完成用户的请求操作后，会向 CPU 发出中断信号，此时，CPU 就会暂停执行下一条即将要执行的指令，转而去执行中断信号对应的处理程序，如果先前执行的指令是在用户态下，则自然就发生从用户态到内核态的转换。

注意： 系统调用的本质其实也是中断，相对于外围设备的硬中断，这种中断称为软中断，这是操作系统为用户特别开放的一种中断，如 Linux int 80h 中断。所以，从触发方式和效果上来看，这三种切换方式是完全一样的，都相当于是执行了一个中断响应的过程。但是从触发的对象来看，系统调用是进程主动请求切换的，而异常和硬中断则是被动的。

总结

本文仅是从宏观的角度去理解 Linux 用户态和内核态的设计，并没有去深究它们的具体实现方式。从实现上来看，必须要考虑到的一点我想就是性能问题，因为用户态和内核态之间的切换会消耗大量资源。

PS：文章未经我允许，不得转载，否则后果自负。

–END–

欢迎扫👇的二维码关注我的微信公众号，后台回复「m」，可以获取往期所有技术博文推送，更多资料回复下列关键字获取。

Linux

CPU 拓扑：从 SMP 谈到 NUMA （理论篇）

2018-05-10

Linux

文章首发于我的公众号「Linux云计算网络」，欢迎关注，第一时间掌握技术干货！

本文的一些概念依赖于上一篇 “CPU 拓扑：从 SMP 谈到 NUMA （理论篇）”，如果你对这块还没有概念，建议看完那篇再来看，如果对这块有自己独到的见解，欢迎探讨。

本文主要会侧重 NUMA 这块，我会通过自己的环境验证 NUMA 的几个概念，以便对 NUMA 的架构有个较深的印象。

NUMA 的几个概念：Node，Socket，Core，Thread

NUMA 技术的主要思想是将 CPU 进行分组，Node 即是分组的抽象，一个 Node 表示一个分组，一个分组可以由多个 CPU 组成。每个 Node 都有自己的本地资源，包括内存、IO 等。每个 Node 之间通过互联模块（QPI）进行通信，因此每个 Node 除了可以访问自己的本地内存之外，还可以访问远端 Node 的内存，只不过性能会差一些，一般用 distance 这个抽象的概念来表示各个 Node 之间互访资源的开销。

Node 是一个逻辑上的概念，与之相对的 Socket，是物理上的概念。它表示一颗物理 CPU 的封装，是主板上的 CPU 插槽，所以，一般就称之为插槽（敲黑板，这 Y 不是套接字吗？emmm……）

Core 就是 Socket 里独立的一组程序执行单元，称之为物理核。有了物理核，自然就有逻辑核，Thread 就是逻辑核。更专业的说法应该称之为超线程。

超线程是为了进一步提高 CPU 的处理能力，Intel 提出的新型技术。它能够将一个 Core 从逻辑上划分成多个逻辑核（一般是两个），每个逻辑核有独立的寄存器和中断逻辑，但是一个 Core 上的多个逻辑核共享 Core 内的执行单元和 Cache，频繁调度可能会引起资源竞争，影响性能。超线程必须要 CPU 支持才能开启。

综上所述，一个 NUMA Node 可以有一个或者多个 Socket，每个 Socket 也可以有一个（单核）或者多个（多核）Core，一个 Core 如果打开超线程，则会变成两个逻辑核（Logical Processor，简称 Processor）。

所以，几个概念从大到小排序依次是：

Node > Socket > Core > Processor。

验证 CPU 拓扑

了解了以上基本概念，下面在实际环境中查看这些概念并验证。

Node

用 numactl --hardware 查看当前系统的 NUMA Node（numactl 是设定进程 NUMA 策略的命令行工具）：

Linux # numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 12 13 14 15 16 17
node 0 size: 49043 MB
node 0 free: 20781 MB
node 1 cpus: 6 7 8 9 10 11 18 19 20 21 22 23
node 1 size: 49152 MB
node 1 free: 31014 MB
node distances:
node   0   1 
0:  10  21 
1:  21  10

可以得出的信息有：1）系统的 Node 数为 2；2）每个 Node 包含的 Processor 数为 12；3）每个 Node 的总内存大小和空闲内存大小；4）每个 Node 之间的 distance。

还可以查看 /sys/devices/system/node/ 目录，这里记录着具体哪些 Node。

Socket

/proc/cpuinfo 中记录着 Socket 信息，用 “physical id” 表示，可以用 cat /proc/cpuinfo | grep "physical id" 查看：

Linux # cat /proc/cpuinfo | grep "physical id"
physical id     : 0
physical id     : 0
physical id     : 0
physical id     : 0
physical id     : 1
physical id     : 1
physical id     : 1
physical id     : 1

可以看到有 2 个 Socket，我们还可以查看以下这几种变种：

1）查看有几个 Socket

Linux # grep 'physical id' /proc/cpuinfo | awk -F: '{print $2 | "sort -un"}'

0
1

1
2
3

Linux # grep 'physical id' /proc/cpuinfo | awk -F: '{print $2 | "sort -un"}' | wc -l

2

2）查看每个 Socket 有几个 Processor

Linux # grep 'physical id' /proc/cpuinfo | awk -F: '{print $2}' | sort | uniq -c

12 0
12 1

3）查看每个 Socket 有哪几个 Processor

Linux # awk -F: '{ 
>     if ($1 ~ /processor/) {
>         gsub(/ /,"",$2);
>         p_id=$2;
>     } else if ($1 ~ /physical id/){
>         gsub(/ /,"",$2);
>         s_id=$2;
>         arr[s_id]=arr[s_id] " " p_id
>     }
> } 
> 
> END{
>     for (i in arr) 
>         print arr[i];
> }' /proc/cpuinfo | cut -c2-

0 1 2 3 4 5 12 13 14 15 16 17
6 7 8 9 10 11 18 19 20 21 22 23

Core

同样在 /proc/cpuinfo 中查看 Core 信息：

Linux # cat /proc/cpuinfo |grep "core id" | sort -u
core id    : 0
core id    : 1
core id    : 2
core id    : 3
core id    : 4
core id    : 5

上面的结果表明一个 Socket 有 5 个 Core。上面查到有 2 个 Socket，则一共就有 10 个 Core。

Processor

上面查看 Socket 信息时已经能够得到 Processor 的信息，总共有 24 个 Processor，不过也可以直接从 /proc/cpuinfo 中获取：

1）获取总的 Processor 数，查看 “processor” 字段：

1
2
3

Linux # cat /proc/cpuinfo | grep "processor" | wc -l

24

2）获取每个 Socket 的 Processor 数，查看 “siblings” 字段：

1
2
3

Linux # cat /proc/cpuinfo | grep "siblings" | sort -u

12

Cache

Cache 也一样通过 /proc/cpuinfo 查看：

processor  : 0

cache size  : 15360 KB

cache_alignment  : 64

不过这里的值 cache size 比较粗略，我们并不知道这个值是哪一级的 Cache 值（L1？L2？L3？），这种方法不能确定，我们换一种方法。

其实详细的 Cache 信息可以通过 sysfs 查看，如下：

比如查看 cpu0 的 cache 情况：

1
2
3

Linux # ls /sys/devices/system/cpu/cpu0/cache/

index0/  index1/  index2/  index3/

其中包含四个目录：
index0 存 L1 数据 Cache，index1 存 L1 指令 Cache，index2 存 L2 Cache，index3 存 L3 Cache。每个目录里面包含一堆描述 Cache 信息的文件。我们选 index0 具体看下：

其中，shared_cpu_list 和 shared_cpu_map 表示意思是一样的，都表示该 cache 被哪几个 processor 共享。对 shared_cpu_map 具体解释一下。

这个值表面上看是二进制，但其实是 16 进制，每个数字有 4 个bit，代表 4 个 cpu。比如上面的 001001 拆开后是：

1	0000 0000 0001 0000 0000 0001，1 bit 处即对应 cpu 标号，即 cpu0 和 cpu12。

同样我们可以对其他 index 进行统计，可以得出：
/proc/cpuinfo 中的 cache size 对应的 L3 Cache size。

最后，综合以上所有信息我们可以绘制出一下的 CPU 拓扑图：

我们发现以上命令用得不太顺手，要获取多个数据需要输入多条命令，能不能一条命令就搞定，当然是有的，lscpu 就可以做到，如下：

Linux # lscpu 
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                24   //共有24个逻辑CPU（threads）
On-line CPU(s) list:   0-23
Thread(s) per core:    2   //每个 Core 有 2 个 Threads
Core(s) per socket:    12  //每个 Socket 有 12 个 Threads
Socket(s):             2  //共有 2 个 Sockets
NUMA node(s):          2  //共有 2 个 Nodes
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 63
Stepping:              2
CPU MHz:               2401.000
BogoMIPS:             4803.16
Virtualization:        VT-x
L1d cache:             32K  //L1 data cache 32k
L1 cache:             32K   //L1 instruction cache 32k  
L2 cache:              256K //L2 instruction cache 256k
L3 cache:              15360K //L3 instruction cache 15M
NUMA node0 CPU(s):     0-5,12-17
NUMA node1 CPU(s):     6-11,18-23

当然了，没有完美的命令，lscpu 也只能显示一些宽泛的信息，只是相对比较全面而已，更详细的信息，比如 Core 和 Cache 信息就得借助 cpuinfo 和 sysfs 了。

下面给大家提供一个脚本，能够比较直观的显示以上所有信息，有 shell 版的和 python 版的（不是我写的，文末附上了引用出处）。

大家有需要可以回复 “CPU” 获取，我就不贴出来了，显示的结果大概就是长下面这个样子：

python 版：

============================================================
Core and Socket Information (as reported by '/proc/cpuinfo')
============================================================

cores =  [0, 1, 2, 3, 4, 5]

sockets =  [0, 1]


Socket 0        Socket 1        

--------        --------        

Core 0 [0, 12]         [6, 18]         

Core 1 [1, 13]         [7, 19]         

Core 2 [2, 14]         [8, 20]         

Core 3 [3, 15]         [9, 21]         

Core 4 [4, 16]         [10, 22]        

Core 5 [5, 17]         [11, 23]

Reference：

玩转 CPU 拓扑：
http://blog.itpub.net/645199/viewspace-1421876/
NUMA 体系结构详解
https://blog.csdn.net/ustc_dylan/article/details/45667227（shell 代码引用）
dpdk 源代码（python 代码引用）

PS：文章未经我允许，不得转载，否则后果自负。

–END–

欢迎扫👇的二维码关注我的微信公众号，后台回复「m」，可以获取往期所有技术博文推送，更多资料回复下列关键字获取。

Linux CPU NUMA

CPU 拓扑：从 SMP 谈到 NUMA （理论篇）

2018-05-03

Linux

文章首发于我的公众号「Linux云计算网络」，欢迎关注，第一时间掌握技术干货！

随着计算机技术（特别是以芯片为主的硬件技术）的快速发展，CPU 架构逐步从以前的单核时代进阶到如今的多核时代，在多核时代里，多颗 CPU 核心构成了一个小型的“微观世界”。每颗 CPU 各司其职，并与其他 CPU 交互，共同支撑起了一个“物理世界”。从这个意义上来看，我们更愿意称这样的“微观世界”为 CPU 拓扑，就像一个物理网络一样，各个网络节点通过拓扑关系建立起连接来支撑起整个通信系统。

单核 or 多核 or 多 CPU or 超线程 ?

在单核时代，为了提升 CPU 的处理能力，普遍的做法是提高 CPU 的主频率，但一味地提高频率对于 CPU 的功耗也是影响很大的（CPU 的功耗正比于主频的三次方）。

另外一种做法是提高 IPC （每个时钟周期内执行的指令条数），这种做法要么是提高指令的并行度，要么是增加核数。显然，后一种方法更具有可扩展性，这也是摩尔定律的必然性。

CPU 的性能到底是如何体现的呢？为了弄清楚这个问题，我们结合单核 CPU 和多核 CPU 的结构来进一步剖析。

首先，对于一个单核结构，即一颗物理 CPU 封装里只集成了一个物理核心，其主要组件可以简化为：CPU 寄存器集合、中断逻辑、执行单元和 Cache，如下图：

对于一个多线程程序，主要通过时间片轮转的方式来获得 CPU 的执行权，从内部来看，这其实是串行执行的，性能自然并不怎么高。

其次，对于多核结构，则是在一颗物理 CPU 封装里集成了多个对等的物理核心，所谓对等，就是每个核心都有相同的内部结构。多个核心之间通过芯片内部总线来完成通信。随着 CPU 制造工艺的提升，每颗 CPU 封装中集成的物理核心也在不断提高。

对于一个多线程程序，这种情况能够实现真正的并发，但线程在不同核之间切换会存在一定的开销，但由于走的是芯片内部总线，开销相对会比较小。

除了上述两种结构，还有另外一种结构是多 CPU 结构，也就是多颗单独封装的 CPU 通过外部总线相连，构成的一个统一的计算平台。每个 CPU 都需要独立的电路支持，有自己的 Cache。它们之间的通信通过主板上的总线来完成。

同样对于一个多线程程序，不同于上一种情况的是，线程间的切换走的是外部总线，延迟较大，开销自然较大，而且对于有共享的数据还会因 Cache 一致性带来一定的开销（关于 Cache 下一小节说明）。

上述结构，一个 CPU 核心同一时间内只能执行一个线程，效率低下，为了提高 CPU 的利用率，CPU 芯片厂商又推出超线程（Hyper-Thread-ing）技术，即让一个物理核心同时执行多个线程，使整体性能得到提升。虽然物理上只有一个核心，但逻辑上被划分了多个逻辑核心，它们之间是完全隔离的。

对于每个逻辑核心，拥有完整独立的寄存器集合和中断逻辑，共享执行单元和 Cache。由于是共享执行单元，所以对高 IPC 的应用，其性能提升有限。

Cache

Cache 是一种 SRAM （Static Random Access Memory，静态访问随机存储器）。出于成本和生产工艺考虑，一般将 Cache 分为三级。一级（L1）访问速度最快，但是容量最小，一般只有几十 KB；二级（L2）次之，一般有几百 KB 到几 MB 不等，三级（LLC，Last Level Cache）最慢，但是容量也最大，一般有几 MB 到几十 MB。

一级 Cache 又分为数据 Cache 和指令 Cache，顾名思义，数据 Cache 用来存数据，指令 Cache 用来存指令。下图是一个简单的 Cache 系统逻辑示意图。

在多核结构中，每个物理核心都拥有独立的一级 Cache 和二级 Cache，而三级 Cache 是所有核心共享。这种共享需要解决的一个问题是公平地为每个核心分配 Cache 大小，避免 Cache 命中率低的问题。

对于现代计算机系统，说到 Cache，不得不提 TLB（Translation Look-aside Buffer） Cache。简单理解，如果说 Cache 存放的是内存中的内容，那么 TLB Cache 存放的是页表项。

为什么页表项需要用 Cache 存，原因当然是快。你可能觉得用三级 Cache 存就行了，为什么还要专门上 TLB Cache。

这里有两点考虑，一点是 TLB 采用基于内容的访问存储器 CAM，这种存储器能做到根据虚拟地址查询直接返回物理地址，效率极高，不需要像传统方式那样采用多级页表查询。另外一点是 Cache 的“淘汰”机制决定，Cache 会根据算法淘汰掉那些不常使用的内容，这对于页表这种需要频繁访问（每次程序寻址都要访问页表）的特性显然是矛盾的，所以就需要专门为页表提供一种特殊的 Cache，即 TLB Cache。

SMP or NUMA or MPP?

如果说前面咱们讨论的是 CPU 内部的“微观世界”，那么本节将跳出来，探讨一个系统级的“宏观世界”。

首先是 SMP，对称多处理器系统，指的是一种多个 CPU 处理器共享资源的电脑硬件架构，其中，每个 CPU 没有主从之分，地位平等，它们共享相同的物理资源，包括总线、内存、IO、操作系统等。每个 CPU 访问内存所用时间都是相同的，因此这种系统也被称为一致存储访问结构（UMA，Uniform Memory Access）。

这种系统由于共享资源，不可避免地要加锁来解决资源竞争的问题，带来一定的性能开销，另外，扩展能力还非常有限，实验证明，SMP 系统最好的情况是有 2-4 个 CPU，适用于 PC、笔记本电脑和小型服务器等。

tips: 查看系统是否是 SMP 结构：

1	ls /sys/devices/system/node/ # 如果只看到一个 node0 那就是 SMP 架构

为了应对大规模的系统要求（特别是云计算环境），就研制出了 NUMA 结构，即非一致存储访问结构。

这种结构引入了 CPU 分组的概念，用 Node 来表示，一个 Node 可能包含多个物理 CPU 封装，从而包含多个 CPU 物理核心。每个 Node 有自己独立的资源，包括内存、IO 等。每个 Node 之间可以通过互联模块总线（QPI）进行通信，所以，也就意味着每个 Node 上的 CPU 都可以访问到整个系统中的所有内存，但很显然，访问远端 Node 的内存比访问本地内存要耗时很多，这也是 NUMA 架构的问题所在，我们在基于 NUMA 架构开发上层应用程序要尽可能避免跨 Node 内存访问。

NUMA 架构在 SMP 架构的基础上通过分组的方式增强了可扩展性，但从性能上看，随着 CPU 数量的增加，并不能线性增加系统性能，原因就在于跨 Node 内存访问的问题。所以，一般 NUMA 架构最多支持几百个 CPU 就不错了。

但对于很多大型计算密集型的系统来说，NUMA 显然有些吃力，所以，后来又出现了 MPP 架构，即海量并行处理架构。这种架构也有分组的概念，但和 NUMA 不同的是，它不存在异地内存访问的问题，每个分组内的 CPU 都有自己本地的内存、IO，并且不与其他 CPU 共享，是一种完全无共享的架构，因此它的扩展性最好，可以支持多达数千个 CPU 的量级。

总结

1、在芯片技术已然发展成熟的今天，性能低，上核不是问题，但上核就一定能提高性能吗，另外上核怎么很好地利用多核来完成自身进化，这些问题都值得深思。

2、NUMA 架构算是多核时代应用较大的一种 CPU 架构，本文从核心谈到系统，让大家有个全面的了解，下文会特别针对 NUMA 架构做一些实验验证。

Reference：
1.《深入浅出 DPDK》

SMP、NUMA、MPP体系结构介绍：
https://www.cnblogs.com/yubo/archive/2010/04/23/1718810.html

PS：文章未经我允许，不得转载，否则后果自负。

–END–

欢迎扫👇的二维码关注我的微信公众号，后台回复「m」，可以获取往期所有技术博文推送，更多资料回复下列关键字获取。

Linux CPU NUMA

Linux 下几种零拷贝的方法

2018-01-05

Linux

文章首发于我的公众号「Linux云计算网络」，欢迎关注，第一时间掌握技术干货！

本文讲解 Linux 的零拷贝技术，我在「云计算技能图谱」中说过，云计算是一门很庞大的技术学科，融合了很多技术，Linux 算是比较基础的技术，所以，学好 Linux 对于云计算的学习会有比较大的帮助。

本文借鉴并总结了几种比较常见的 Linux 下的零拷贝技术，相关的引用链接见文后，大家如果觉得本文总结得太抽象，可以转到链接看详细解释。

为什么需要零拷贝

传统的 Linux 系统的标准 I/O 接口（read、write）是基于数据拷贝的，也就是数据都是 copy_to_user 或者 copy_from_user，这样做的好处是，通过中间缓存的机制，减少磁盘 I/O 的操作，但是坏处也很明显，大量数据的拷贝，用户态和内核态的频繁切换，会消耗大量的 CPU 资源，严重影响数据传输的性能，有数据表明，在Linux内核协议栈中，这个拷贝的耗时甚至占到了数据包整个处理流程的57.1%。

什么是零拷贝

零拷贝就是这个问题的一个解决方案，通过尽量避免拷贝操作来缓解 CPU 的压力。Linux 下常见的零拷贝技术可以分为两大类：一是针对特定场景，去掉不必要的拷贝；二是去优化整个拷贝的过程。由此看来，零拷贝并没有真正做到“0”拷贝，它更多是一种思想，很多的零拷贝技术都是基于这个思想去做的优化。

零拷贝的几种方法

原始数据拷贝操作

在介绍之前，先看看 Linux 原始的数据拷贝操作是怎样的。如下图，假如一个应用需要从某个磁盘文件中读取内容通过网络发出去，像这样：

1
2
3

while((n = read(diskfd, buf, BUF_SIZE)) > 0)

write(sockfd, buf , n);

那么整个过程就需要经历：1）read 将数据从磁盘文件通过 DMA 等方式拷贝到内核开辟的缓冲区；2）数据从内核缓冲区复制到用户态缓冲区；3）write 将数据从用户态缓冲区复制到内核协议栈开辟的 socket 缓冲区；4）数据从 socket 缓冲区通过 DMA 拷贝到网卡上发出去。

可见，整个过程发生了至少四次数据拷贝，其中两次是 DMA 与硬件通讯来完成，CPU 不直接参与，去掉这两次，仍然有两次 CPU 数据拷贝操作。

方法一：用户态直接 I/O

这种方法可以使应用程序或者运行在用户态下的库函数直接访问硬件设备，数据直接跨过内核进行传输，内核在整个数据传输过程除了会进行必要的虚拟存储配置工作之外，不参与其他任何工作，这种方式能够直接绕过内核，极大提高了性能。

缺陷：

1）这种方法只能适用于那些不需要内核缓冲区处理的应用程序，这些应用程序通常在进程地址空间有自己的数据缓存机制，称为自缓存应用程序，如数据库管理系统就是一个代表。

2）这种方法直接操作磁盘 I/O，由于 CPU 和磁盘 I/O 之间的执行时间差距，会造成资源的浪费，解决这个问题需要和异步 I/O 结合使用。

方法二：mmap

这种方法，使用 mmap 来代替 read，可以减少一次拷贝操作，如下：

1
2
3

buf = mmap(diskfd, len);

write(sockfd, buf, len);

应用程序调用 mmap ，磁盘文件中的数据通过 DMA 拷贝到内核缓冲区，接着操作系统会将这个缓冲区与应用程序共享，这样就不用往用户空间拷贝。应用程序调用write ，操作系统直接将数据从内核缓冲区拷贝到 socket 缓冲区，最后再通过 DMA 拷贝到网卡发出去。

缺陷：

1）mmap 隐藏着一个陷阱，当 mmap 一个文件时，如果这个文件被另一个进程所截获，那么 write 系统调用会因为访问非法地址被 SIGBUS 信号终止，SIGBUS 默认会杀死进程并产生一个 coredump，如果服务器被这样终止了，那损失就可能不小了。

解决这个问题通常使用文件的租借锁：首先为文件申请一个租借锁，当其他进程想要截断这个文件时，内核会发送一个实时的 RT_SIGNAL_LEASE 信号，告诉当前进程有进程在试图破坏文件，这样 write 在被 SIGBUS 杀死之前，会被中断，返回已经写入的字节数，并设置 errno 为 success。

通常的做法是在 mmap 之前加锁，操作完之后解锁：

if(fcntl(diskfd, F_SETSIG, RT_SIGNAL_LEASE) == -1) {

perror("kernel lease set signal");

return -1;

}

/* l_type can be F_RDLCK F_WRLCK  加锁*/

/* l_type can be  F_UNLCK 解锁*/

if(fcntl(diskfd, F_SETLEASE, l_type)){

perror("kernel lease set type");

return -1;

}

方法三：sendfile

从Linux 2.1版内核开始，Linux引入了sendfile，也能减少一次拷贝。

1
2
3

#include<sys/sendfile.h>

ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

sendfile 是只发生在内核态的数据传输接口，没有用户态的参与，自然避免了用户态数据拷贝。它指定在 in_fd 和 out_fd 之间传输数据，其中，它规定 in_fd 指向的文件必须是可以 mmap 的，out_fd 必须指向一个套接字，也就是规定数据只能从文件传输到套接字，反之则不行。sendfile 不存在像 mmap 时文件被截获的情况，它自带异常处理机制。

缺陷：

1）只能适用于那些不需要用户态处理的应用程序。

方法四：DMA 辅助的 sendfile

常规 sendfile 还有一次内核态的拷贝操作，能不能也把这次拷贝给去掉呢？

答案就是这种 DMA 辅助的 sendfile。

这种方法借助硬件的帮助，在数据从内核缓冲区到 socket 缓冲区这一步操作上，并不是拷贝数据，而是拷贝缓冲区描述符，待完成后，DMA 引擎直接将数据从内核缓冲区拷贝到协议引擎中去，避免了最后一次拷贝。

缺陷：

1）除了3.4 中的缺陷，还需要硬件以及驱动程序支持。

2）只适用于将数据从文件拷贝到套接字上。

方法五：splice

splice 去掉 sendfile 的使用范围限制，可以用于任意两个文件描述符中传输数据。

#define _GNU_SOURCE         /* See feature_test_macros(7) */

#include <fcntl.h>

ssize_t splice(int fd_in, loff_t *off_in, int fd_out, loff_t *off_out, size_t len, unsigned int flags);

但是 splice 也有局限，它使用了 Linux 的管道缓冲机制，所以，它的两个文件描述符参数中至少有一个必须是管道设备。

splice 提供了一种流控制的机制，通过预先定义的水印（watermark）来阻塞写请求，有实验表明，利用这种方法将数据从一个磁盘传输到另外一个磁盘会增加 30%-70% 的吞吐量，CPU负责也会减少一半。

缺陷：

1）同样只适用于不需要用户态处理的程序

2）传输描述符至少有一个是管道设备。

方法六：写时复制

在某些情况下，内核缓冲区可能被多个进程所共享，如果某个进程想要这个共享区进行 write 操作，由于 write 不提供任何的锁操作，那么就会对共享区中的数据造成破坏，写时复制就是 Linux 引入来保护数据的。

写时复制，就是当多个进程共享同一块数据时，如果其中一个进程需要对这份数据进行修改，那么就需要将其拷贝到自己的进程地址空间中，这样做并不影响其他进程对这块数据的操作，每个进程要修改的时候才会进行拷贝，所以叫写时拷贝。这种方法在某种程度上能够降低系统开销，如果某个进程永远不会对所访问的数据进行更改，那么也就永远不需要拷贝。

缺陷：

需要 MMU 的支持，MMU 需要知道进程地址空间中哪些页面是只读的，当需要往这些页面写数据时，发出一个异常给操作系统内核，内核会分配新的存储空间来供写入的需求。

方法七：缓冲区共享

这种方法完全改写 I/O 操作，因为传统 I/O 接口都是基于数据拷贝的，要避免拷贝，就去掉原先的那套接口，重新改写，所以这种方法是比较全面的零拷贝技术，目前比较成熟的一个方案是最先在 Solaris 上实现的 fbuf （Fast Buffer，快速缓冲区）。

Fbuf 的思想是每个进程都维护着一个缓冲区池，这个缓冲区池能被同时映射到程序地址空间和内核地址空间，内核和用户共享这个缓冲区池，这样就避免了拷贝。

缺陷：

1）管理共享缓冲区池需要应用程序、网络软件、以及设备驱动程序之间的紧密合作

2）改写 API ，尚处于试验阶段。

高性能网络 I/O 框架——netmap

Netmap 基于共享内存的思想，是一个高性能收发原始数据包的框架，由Luigi Rizzo 等人开发完成，其包含了内核模块以及用户态库函数。其目标是，不修改现有操作系统软件以及不需要特殊硬件支持，实现用户态和网卡之间数据包的高性能传递。

在 Netmap 框架下，内核拥有数据包池，发送环\接收环上的数据包不需要动态申请，有数据到达网卡时，当有数据到达后，直接从数据包池中取出一个数据包，然后将数据放入此数据包中，再将数据包的描述符放入接收环中。内核中的数据包池，通过 mmap 技术映射到用户空间。用户态程序最终通过 netmap_if 获取接收发送环 netmap_ring，进行数据包的获取发送。