なぜ `strace`はこのプロセスが何かを待っていることを示さないのですか？

強大なstrace私を失望させた。これはどのようにして可能ですか？

time fooこれは、foo実行に数秒かかる（ "実際の"）が、ユーザー空間（ "user"）とカーネル（ "sys"）の両方で無視できるCPU時間を使用することを示しています。好奇心のために、foo以下に定義されています。

そのため、CPU命令を実行するのではなく、他の何かを待つのにほとんどの時間を費やしています。通常、私はそれがどのように待っているかを見ることができますstrace-つまり、どのシステムコールが長期間ブロックしているのか。残念ながら、このアプローチは機能しませんでした。

strace -ttt -T -C -w fooは、システムコール、タイムスタンプ、およびシステムコールに費やされた（実際の）時間の概要を示しています。しかし、この特定のプロセスは、システムコールの内部で費やされる全体（実）時間はごくわずかであることを示しました。

fooですjournalctl -b -u dev-hugepages.mount。これを再現するために、毎回異なるsystemdユニットへの最後の引数を変更しなければならなかったことを除いて。つまり、調査対象の遅延は、あるsystemdユニットのログを取得しようとしたときに初めて発生しました。 編集：主な質問に答えた後、私はこの遅延を再現する問題が発生している理由にも気付きました。

このプロセスに費やされる時間は特定の問題であり、明らかにすべてのシステムで発生するわけではありません。https://github.com/systemd/systemd/issues/7963

この問題が発生する通常の理由は、プロセスがページフォールトでブロックしていることです。これらは、メモリマッピングakaを通じて実行されるファイルの読み取りまたは書き込みですmmap()。mmap()システムコールのトレースに気づいたかもしれません。

シェル組み込みの/usr/bin/time代わりにプログラムを使用した場合はtime、次のことに気づいたかもしれません。

0.04user 0.10system 0:02.29elapsed 6%CPU (0avgtext+0avgdata 40464maxresident)k
73632inputs+0outputs (376major+1081minor)pagefaults 0swaps

majorページフォルトは、ファイルシステムIOを必要とするものです。 minorページフォルトはそれほど重要ではありません（おそらく「TLBミス」のみ）。

inputs読んだページの総数だと思う。現在、ファイルマップページは常に同じサイズだと思います。ほとんどの場合4096バイトですが、チェックできますgetconf PAGESIZE。

したがって、これは290メガバイトに相当し、毎秒100メガバイトを超える速度で読み取ります。これは、私のようなハードディスクの標準速度です。謎解きました！

また、このプロセスには完全に空きCPUがあることを前提としています。そうしないと、他のプロセスがCPUを解放するのを待って、プロセスが単にブロックされる可能性があります。

straceシステムコールが原因でプロセスがカーネルに入ったとき（そしてカーネルから出たとき）にのみ表示されます。または、unixシグナルが配信されたとき。ただしstrace、まったく表示されない他の種類の割り込みがあります。したがって、これらには

• ページ不在。
• タイマー割り込み。これは、現在のプロセスがCPUで割り当てられたタイムスライスを使い果たしたときに、別のプロセスに切り替えるために使用されます。