關於系統呼叫和核心模組（核心服務並行）的幾個問題
我對系統呼叫和核心模組有幾個問題。
- 假設我們有兩個應用程序（A 和 B），每個應用程序都執行在不同的核心上。(A-CPU 0, B-CPU 1) 當兩個應用程序並行呼叫同一個系統呼叫時，它們是並行執行的嗎？如果是這樣，系統呼叫執行的 CPU 核心是什麼？系統呼叫是否在其呼叫者的 CPU 核心上執行？
- 假設我們有一個核心模組，兩個應用程序（A 和 B）通過 ioctl（並行）呼叫核心模組的相同函式。它們是並行執行的嗎？如果是這樣，服務核心模組功能的 CPU 核心是什麼。如果不是，那麼為多個應用程序提供並行核心模組功能的最有效方法是什麼？
當 SMP 支持首次添加到 Linux 時，它使用“巨型鎖”或“BKL” （大核心鎖），直到幾年前它仍然存在。這有效地使核心成為單執行緒的（我相信硬體中斷服務除外），因此只能有一個系統呼叫處於活動狀態，這當然限制了許多類型工作負載的性能。
隨著時間的推移，BKL 被細粒度鎖定所取代，一些系統呼叫可以完全並發執行，而另一些則不能完全並發。舉一個簡單的例子，考慮在 Linux 核心中分配 PID 和程序創建。PID 使用點陣圖實現，PID 編號的分配和釋放可以通過無鎖原子操作來完成。但是，程序表的維護並不是那麼簡單，這是通過“任務列表”鎖來完成的，以確保相關資料結構的完整性（
pid_hash）。然後回答問題：
當兩個應用程序並行呼叫同一個系統呼叫時，它們是並行執行的嗎？
假設是當代核心，是的。但是，根據系統呼叫，它們可能會旋轉、屈服或以其他方式推遲某些操作。當使用互斥鎖或鎖時，並發呼叫將無法更新相同的資料結構，或同時訪問相同的硬體。
如果是這樣，系統呼叫執行的 CPU 核心是什麼？系統呼叫是否在其呼叫者的 CPU 核心上執行？
它將在呼叫 CPU 上啟動，它可能會根據系統呼叫和系統中其他地方發生的情況重新調度到另一個 CPU，除非您設置了嚴格的親和力。如果您稍微考慮一下getcpu()系統呼叫的行為，它應該會更清楚（忽略它可能不是 x86 上真正的系統呼叫的事實）。
假設我們有一個核心模組，兩個應用程序（A 和 B）通過 ioctl（並行）呼叫核心模組的相同函式。它們是並行執行的嗎？
是的，該模組預計將根據需要使用細粒度鎖定和其他同步原語。
如果是這樣，服務核心模組功能的 CPU 核心是什麼。
同上，它將在呼叫 CPU 上啟動。
如果不是，那麼為多個應用程序提供並行核心模組功能的最有效方法是什麼？
根據模組（和硬體），效率取決於對正確鎖定的謹慎和最少使用（可能避免自旋鎖，減少記憶體複製等），以及正確使用處理器親和性。如果您詢問系統呼叫在哪裡沒有或不能同時處理，那麼很難給出一個好的答案。通過將驅動程序的某些部分委託給多執行緒使用者空間守護程序可能是可能的（我在一些加密加速器中觀察到了這一點，其中加速器本身一次只能執行一個操作，並且一些小操作更快中央處理器）。
免費的 PDF 書籍Linux 設備驅動程序（第 3 版）對於此類工作非常寶貴，尤其是第 5 章：並發和競爭條件。