最近开发用到fuse文件系统，这个文件系统的功能实现是在用户态下进行的，然而它的文件系统操作接口必须在内核态注册，所以需要研究一下内核态到用户态的开销到底如何。
下面这个例子是在stackoverflow上看到的，基本能反映开销的差异了：
在linux测试这个测试程序，getuid是一个系统调用，返回当前用户的id

1 #include <unistd.h>
2 
3 #define MAX 100000000
4 int main() {
5   int ii;
6   for (ii=0; ii<MAX; ii++) getuid();
7   return 0;
8 }

结果显示循环1亿次用时8秒多
real 0m8.438s
user 0m3.952s
sys 0m4.485s

当使用如下程序测试时，

 1 #include <unistd.h>
 2 #define MAX 100000000
 3 
 4 int _getid()
 5 {
 6         return 1;
 7 }
 8 
 9 int main() {
10   int ii;
11   for (ii=0; ii<MAX; ii++) _getid();
12   return 0;
13 }

运行结果如下：

real 0m0.305s
user 0m0.304s
sys 0m0.000s

这时时间消耗明显减少了很多。

两个程序时间的消耗的差异主要在于内核态和用户态的切换，每一次循环都涉及一次用户态->内核态->用户态的切换，所以消耗的时间就多了很多。

同时也说明我必须要修改fuse的各个文件接口的功能实现来让它不再反复切换用户内核态了。

前文

纸上得来终觉浅，希望通过直观的代码测试出来内核切换的开销

测试过程

通过两段程序进行对比，第一段是进行了系统调用获取uid，第二段是直接返回一个uid的值

gcc callsystem.c -o callsystem
gcc calluser.c -o calluser

测试结果

我们可以看到带有系统调用耗时需要11秒左右，用户态的耗时0.15s，开销上的差异非常明显

系统调用的代码

#include<unistd.h>
#define MAX 50000000
int main(){
        int ii;
        for(ii = 0;ii < MAX; ii++) getuid();
        return 0;
}

非系统调用的代码

#include<unistd.h>
#define MAX 50000000

int _getuid(){
        return 1001;
}
int main(){
        int ii;
        for(ii = 0;ii < MAX; ii++) _getuid();
        return 0;
}

strace 跟踪系统调用

其实getuid不管系统还是用户，都是返回数字就是，测试下来可以看出差异那么大
我们使用strace跟踪一下调用

strace -c ./callsystem

下面这个uid其实已经跑不出来了，基本也就是在系统调用的时候耗时

系统调用慢的缘由

系统调用其实就是应用程序和内核空间的一票接口，因为服务是在内核中提供的，所以不能直接调用调用流程如下：

实际上，系统调用的过程首先需要把用户态切换成内核态，系统调用过程是通过软中断0x80实现的，这个是比较核心的因素，因为一旦是涉及到其他中断就需要经历和其他中断一样的过程，当年这块可是考试重点：

关键的结论其实就是，宏观上来说CPU利用率是提高了，但是实际上来说中断的工作以及处理恢复工作其实都是非常耗时的，系统调用慢的缘由便是如此！

https://www.cnblogs.com/bakari/p/5520860.html

思考这个问题的导火线是，看到java中的synchronized关键字。

经过编译，synchronized标注的函数会加一个读写锁，一般不推荐使用，因为加锁解锁设计到内核态与用户态的转换，有时转化耗时比函数体执行时间还长，所以不推荐使用。

这个观点在学操作系统的时候作为常识被认知，那背后具体的原理是什么呢？

一句话回答问题：

上面涉及的内核态与用户态切换时系统调用，内核也相当于一个软件，他们切换就相当于从一个软件换用另一个软件————控制计算机的硬件资源，并提供上层应用程序运行的环境。

很受启发，我理解的就是，用户态的程序其实经过编译成底层机器码的，比内核态接口还低级的机器码，系统调用反而是往上走了一个level，相当于调用一个软件包。

具体来说是这样的， 
当程序中有系统调用语句，程序执行到系统调用时，首先使用类似int 80H的软中断指令，保存现场，去的系统调用号，在内核态执行，然后恢复现场，每个进程都会有两个栈，一个内核态栈和一个用户态栈。当执行int中断执行时就会由用户态，栈转向内核栈。系统调用时需要进行栈的切换。而且内核代码对用户不信任，需要进行额外的检查。系统调用的返回过程有很多额外工作，比如检查是否需要调度等。 

系统调用一般都需要保存用户程序得上下文(context), 在进入内核得时候需要保存用户态得寄存器，在内核态返回用户态得时候会恢复这些寄存器得内容。这是一个开销的地方。 如果需要在不同用户程序间切换的话，那么还要更新cr3寄存器，这样会更换每个程序的虚拟内存到物理内存映射表的地址，也是一个比较高负担的操作。

引自：为什么系统调用比普通的函数调用更耗时？用户态和内核态切换的代价在哪？

——————华丽的分割线—————— 
接下来是介绍内核态和用户态

如上图所示，从宏观上来看，Linux操作系统的体系架构分为用户态和内核态（或者用户空间和内核）。内核从本质上看是一种软件——控制计算机的硬件资源，并提供上层应用程序运行的环境。用户态即上层应用程序的活动空间，应用程序的执行必须依托于内核提供的资源，包括CPU资源、存储资源、I/O资源等。为了使上层应用能够访问到这些资源，内核必须为上层应用提供访问的接口：即系统调用。

　　系统调用是操作系统的最小功能单位，这些系统调用根据不同的应用场景可以进行扩展和裁剪，现在各种版本的Unix实现都提供了不同数量的系统调用，如Linux的不同版本提供了240-260个系统调用，FreeBSD大约提供了320个（reference：UNIX环境高级编程）。我们可以把系统调用看成是一种不能再化简的操作（类似于原子操作，但是不同概念），有人把它比作一个汉字的一个“笔画”，而一个“汉字”就代表一个上层应用，我觉得这个比喻非常贴切。因此，有时候如果要实现一个完整的汉字（给某个变量分配内存空间），就必须调用很多的系统调用。如果从实现者（程序员）的角度来看，这势必会加重程序员的负担，良好的程序设计方法是：重视上层的业务逻辑操作，而尽可能避免底层复杂的实现细节。库函数正是为了将程序员从复杂的细节中解脱出来而提出的一种有效方法。它实现对系统调用的封装，将简单的业务逻辑接口呈现给用户，方便用户调用，从这个角度上看，库函数就像是组成汉字的“偏旁”。这样的一种组成方式极大增强了程序设计的灵活性，对于简单的操作，我们可以直接调用系统调用来访问资源，如“人”，对于复杂操作，我们借助于库函数来实现，如“仁”。显然，这样的库函数依据不同的标准也可以有不同的实现版本，如ISO C 标准库，POSIX标准库等。

　　Shell是一个特殊的应用程序，俗称命令行，本质上是一个命令解释器，它下通系统调用，上通各种应用，通常充当着一种“胶水”的角色，来连接各个小功能程序，让不同程序能够以一个清晰的接口协同工作，从而增强各个程序的功能。同时，Shell是可编程的，它可以执行符合Shell语法的文本，这样的文本称为Shell脚本，通常短短的几行Shell脚本就可以实现一个非常大的功能，原因就是这些Shell语句通常都对系统调用做了一层封装。为了方便用户和系统交互，一般，一个Shell对应一个终端，终端是一个硬件设备，呈现给用户的是一个图形化窗口。我们可以通过这个窗口输入或者输出文本。这个文本直接传递给shell进行分析解释，然后执行。

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

1）系统调用

2）库函数

3）Shell脚本

　　下图是对上图的一个细分结构，从这个图上可以更进一步对内核所做的事有一个“全景式”的印象。主要表现为：向下控制硬件资源，向内管理操作系统资源：包括进程的调度和管理、内存的管理、文件系统的管理、设备驱动程序的管理以及网络资源的管理，向上则向应用程序提供系统调用的接口。从整体上来看，整个操作系统分为两层：用户态和内核态，这种分层的架构极大地提高了资源管理的可扩展性和灵活性，而且方便用户对资源的调用和集中式的管理，带来一定的安全性。

用户态和内核态的切换

　　因为操作系统的资源是有限的，如果访问资源的操作过多，必然会消耗过多的资源，而且如果不对这些操作加以区分，很可能造成资源访问的冲突。所以，为了减少有限资源的访问和使用冲突，Unix/Linux的设计哲学之一就是：对不同的操作赋予不同的执行等级，就是所谓特权的概念。简单说就是有多大能力做多大的事，与系统相关的一些特别关键的操作必须由最高特权的程序来完成。Intel的X86架构的CPU提供了0到3四个特权级，数字越小，特权越高，Linux操作系统中主要采用了0和3两个特权级，分别对应的就是内核态和用户态。运行于用户态的进程可以执行的操作和访问的资源都会受到极大的限制，而运行在内核态的进程则可以执行任何操作并且在资源的使用上没有限制。很多程序开始时运行于用户态，但在执行的过程中，一些操作需要在内核权限下才能执行，这就涉及到一个从用户态切换到内核态的过程。比如C函数库中的内存分配函数malloc()，它具体是使用sbrk()系统调用来分配内存，当malloc调用sbrk()的时候就涉及一次从用户态到内核态的切换，类似的函数还有printf()，调用的是wirte()系统调用来输出字符串，等等。

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

1）当然就是系统调用：原因如上的分析。

2）异常事件： 当CPU正在执行运行在用户态的程序时，突然发生某些预先不可知的异常事件，这个时候就会触发从当前用户态执行的进程转向内核态执行相关的异常事件，典型的如缺页异常。

3）外围设备的中断：当外围设备完成用户的请求操作后，会像CPU发出中断信号，此时，CPU就会暂停执行下一条即将要执行的指令，转而去执行中断信号对应的处理程序，如果先前执行的指令是在用户态下，则自然就发生从用户态到内核态的转换。

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