系統調用與函數調用之間的性能差異

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涉及遠調用和振鈴切換。