我們有一個進程負責按照時間間隔輪詢硬體。我們希望將一個 CPU 核心專門用於此過程。例如，我們希望這個進程始終保持可運行。
我們解決這個問題的第一次嘗試如下：
# Set process to highest priority
nice -n -20 cmd
# Set thread affinity in C for our hardware sampling thread
pthread_setaffinity_np(...)
上述兩個步驟都如預期般運作。我們的線程停留在core3我們設定的位置，並且nice位於-20頂部。
當重新運行ftrace時根據本次討論和這個問題，我們通常會看到以下內容：
> cat trace | grep " 3)" | grep " => "
3) rhd_loc-2735 => <idle>-0
3) <idle>-0 => rhd_loc-2735
3) rhd_loc-2735 => <idle>-0
3) <idle>-0 => rhd_loc-2735
3) rhd_loc-2735 => <idle>-0
3) <idle>-0 => rhd_loc-2735
rhd_loc-2735是我們的流程。
除了上面顯示的內容之外，我們還看到許多kworker-2703切換到核心的情況，有時其他較低優先順序的進程也交換到核心。
我們認為上下文切換的原因是我們的進程與SPI等待的（串行外設接口）進行通信IRQs，並且SPI運行時脈速率比 CPU 核心慢一個數量級。因此，我們的進程花費大量時間等待 SPI/IRQ，例如，它不處於狀態Runnable。無論優先權或關聯性如何，核心都可以自由地將其他行程分配給核心。
這會導致我們的硬體採樣率變得更加可變並且低於應有的水平，因為我們的 CPU 核心並不總是立即準備好處理下一個值SPI，然後提交新的採樣請求。
問題：
我們是否可以 1) 強制所有其他進程遠離核心，以便我們的進程可以立即回應中斷請求，或者 2) 保持主執行緒可運行，以便它始終可用於處理下一個請求？