背景：

GPIOピンが切り替わるのを待つために、ユーザー空間コードでpselectシステムコールを使用します。私はこのスイッチが発生するのに5ミリ秒以上かかるべきではないことを知っており、オシロスコープを使用してこれを確認しました。ただし、混乱することは、pselect呼び出しが返されるまでに最大20ミリ秒かかる場合があります。

調査：

ヒット時に現在時刻をすべて印刷するようにGPIOドライバ、カーネルのpselect実装、glibcライブラリのpselect実装を修正しました。これを使用して、GPIOドライバとカーネルのpselect実装がタイムリーにヒットすることを確認しました。ただし、返されるカーネルpselect呼び出しとカーネルへのglibcシステム呼び出しの直後の行との間には6〜15msの間隔があります。

Cライブラリでシステムコールがどのように実装されているかについて私が理解したのは、アーキテクチャ固有のマクロ "INLINE_SYSCALL"がユーザーモードとカーネルモードの間でCPUを切り替え、引数をカーネルに渡し、実際にカーネル関数を呼び出してからerrno設定を処理するということです（該当する場合）。 ARMでは、このロジックはいくつかのアセンブリ命令のように見えますが、時間がかかりません。

ハードウェアとソフトウェア：

私はARM Cortex A9で実行されているカーネルバージョン4.1.33（プリエンプションリアルタイムパッチを含む）とglibcバージョン2.23を使用しています。

質問):

カーネル関数から返される行とglibcがかなりの時間損失を説明できるカーネルを呼び出した後の行の間に何が起こりますか？

この時間損失の原因をさらに絞り込むために実行できる他のテストはありますか？

更新/編集：

完全な状態を確認するために、pselect ロジックを GPIO ピンの値をできるだけ早く要求する緊密な使用ループに一時的に交換しました。ループはgpioピンの値の変化が観察されたときにのみ終了し、常に5ミリ秒以内に終了します。これはpselectが実際に問題であることを示します。

いくつかの追加のテストの後、ポーリングシステムコールは基本的にpselectと同じことをしますが、pselectを使用したときに観察される時間の不利益を経験しないことがわかりました。だから問題は解決できましたが、それでも可能であれば原因を知りたいです...