タイミング依存の C プロセスでコンテキスト切り替えを回避する方法

タイミング依存の C プロセスでコンテキスト切り替えを回避する方法

時間依存の間隔でハードウェアをポーリングするプロセスがあります。このプロセスに 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を待機しIRQsSPICPU コアよりも 1 桁遅いクロック レートで実行される (シリアル ペリフェラル インターフェイス) と通信するためであると考えられます。したがって、プロセスは SPI/IRQ を待機するのに多くの時間を費やします。つまり、状態ではありませんRunnable。優先度やアフィニティに関係なく、カーネルは他のプロセスをコアに自由に割り当てることができます。

SPIこれにより、CPU コアが常にすぐに次の値を処理して新しいサンプリング要求を送信する準備ができているわけではないため、ハードウェア サンプリング レートが変動しやすくなり、本来よりも低くなります。

質問:

1) 他のすべてのプロセスをコアから除外して、プロセスが割り込み要求にすぐに応答できるようにするか、2) メイン スレッドを実行可能にして、常に次の要求を処理できるようにするか、どちらかを行うことはできますか?

関連情報