系统调用与函数调用之间的性能差异

Question

我经常听到驱动程序开发人员说，这样做有助于避免内核模式切换。 我不明白确切的原因。 首先我的理解是-

1. 系统调用是软件中断。 在x86上，它们是通过使用指令sysenter触发的。 它实际上看起来像是一条分支指令，它从机器特定的寄存器中获取目标。
2. 系统调用实际上不必更改地址空间或进程上下文。
3. 但是，它们确实将寄存器保存在进程堆栈上，并且将堆栈指针更改为内核堆栈。

在这些操作中，syscall几乎像正常的函数调用一样工作。 虽然sysenter的行为可能像一个错误预测的分支，但可能导致处理器管道中的ROB刷新。 即使那还算不错，就像其他任何错误预测的分支一样。

我听说有人在Stack Overflow上回答：

1. 您永远不会知道syscall需要多长时间-[我]是的，但是任何功能都是这样。 所需时间取决于功能
2. 它通常是安排地点。 -[me]进程可以重新安排，即使它始终在用户模式下运行。 例如， while(1); 不保证无上下文切换。

实际的系统调用成本来自哪里？

Answer 1

您没有指明要询问的操作系统。 无论如何，让我尝试一个答案。

CPU指令syscall和sysenter不应与系统调用的概念及其在各个OS中的表示相混淆。

用于在由每个相应的指令所引起的开销的差最好的解释是通过在64和IA-32架构开发者手册的操作部分读取给定的体积2A （对于int ，见3-392页）和体积2B （对于sysenter见4-463页）。 同时也不要忘记浏览iretd和sysexit 。

对该操作的伪代码进行随意计数会得出：

• int 408行
• sysenter 55行

注意：尽管现有的答案很正确，因为sysenter和syscall不是中断，或与中断没有任何关系，但是Linux和Windows世界中的较早内核使用中断来实现其系统调用机制 。 在Linux上，它以前是int 0x80 ，在Windows上是int 0x2E 。 因此，在那些内核版本上，必须对IDT进行灌注以为相应的中断提供中断处理程序。 在较新的系统上，的确如此， sysenter和syscall指令已完全取代了旧方法。 对于sysenter它是MSR（机器专用寄存器） 0x176 ，它使用0x176处理程序的地址进行sysenter （请参阅下面的阅读材料链接）。

---

在Windows上...

与Linux一样，Windows上的系统调用也会导致切换到内核模式。 NT的调度程序不保证线程被授予的时间。 同样，它浪费了线程的时间，甚至可能导致线程饥饿。 通常，可以说用户模式代码可以被内核模式代码抢占（只有很少的非常具体的异常，您肯定会在“高级驱动程序编写类”中得到这些异常）。 如果只看一个例子，这是很合理的。 用户模式代码可以换出-或换而言之，它正在尝试访问的数据。 现在，CPU没有丝毫线索了解如何访问交换/分页文件中的页面，因此需要一个中间步骤。 这也是为什么内核模式代码必须能够抢占用户模式代码的原因。 这也是Windows上出现的最多产的bug检查代码之一，并且主要由第三方驱动程序引起的原因： IRQL_NOT_LESS_OR_EQUAL 。 这意味着驱动程序在无法抢占接触该内存的代码时访问了页面内存。

---

进一步阅读

1. Windows中的SYSENTER和SYSEXIT，作者Geoff Chappell（根据我的经验，这始终值得一读！）
2. Linux 2.6中基于Sysenter的系统调用机制
3. Windows NT平台特定的讨论： Windows NT系统调用如何真正起作用？
4. Windows NT平台的特定讨论： 使用SYSENTER指令进行系统调用优化
5. Windows Internals，第5版，Russinovich等。 等 -第125至132页。
6. KiFastSystemCall ReactOS实现

Answer 2

SYSENTER / SYSCALL 不是软件中断； 这些指令的全部目的是为了避免由于发出IRQ和调用中断处理程序而引起的开销。

将寄存器保存在堆栈上会花费时间，这是系统调用成本的来源之一。

另一个地方来自内核模式开关本身。 它涉及到更改段寄存器-CS，DS，ES，FS，GS，所有这些都必须更改（在x86-64上成本较低，因为段未使用，但是您仍然需要从根本上跳到内核代码）并更改CPU执行环。

得出的结论是：函数调用是（在现代系统中，不使用分段的）近调用，而syscall涉及远调用和振铃切换。