私は以下を持っています前提Linuxの場合：
- シリアルデバイスからpselectを使用してシリアルデータを読み取るプロセスを使用しています
/dev/ttySX。 - データは400Hzの安定した周波数で入力されます。
- このプロセスの待ち時間を最適化するために、いくつかのアクションを使用しました。
- 読み取りスレッドは、アフィニティを使用して 1 つのコアに固定されており、そのコアではどのタスクも実行できません。これはcgroups / cpusetを介して行われます。
- 読み取りスレッドのRT prioは、SCHED_FIFOポリシーを使用して49（IRQプロセスの直下）です。
- 対応するIRQは
/dev/ttyS4同じコアに固定されます。 IRQプロセスもこのコアで実行されます。これは、待ち時間をさらに短縮するために行われる。
- システムは
stress --cpu XX --io XX読み取り値に影響を与える遅延なしに完全にロードされ、読み取り値は400Hzでうまく機能します。
これ質問私の経験：
- 多くのリソースを使用する別の問題があるユーザースペースプロセスがあります。これが実行されると、シリアル読み取りスレッドで膨大な待ち時間スパイクが発生する可能性があります。ハードウェアでシリアルデータの到着時間が2.5ミリ秒であっても、100ミリ秒以上になることがあります。
- 私は一般的な「良い」スケジューラを使用し、多くのスレッドを生成することを除いて、問題の他のユーザースペースプロセスについてあまり知りません。
私のもの質問:
- これをデバッグできるアイデアや方法はありますか？ ftraceを使用することもできますが、どこから始めるべきかわかりません。
- この動作の原因は何ですか？
この時点で、私はどんなヒント/アイデアでも喜んで受け取ります。ありがとうございます！