私はUbuntuでMeasurement Compute DAQを使用してボードに接続されている他のシステムで連続シミュレーションの読み書きを行っています。私はUbuntu 16.04（Linuxカーネル4.15にアップグレード）を約5年間使用してきました。現在のシステムをUbuntu 20.04 - 22.04にアップグレードしようとしています。各オペレーティングシステムにはLinuxカーネル5.10 - 5.15が付属しています。私はすべてのカーネル5.10以上で非常に鋭い（約50ミリ秒）周期的な割り込みのように見えました。したがって、A / Dボードのシステムread（）およびwrite（）呼び出しに影響を与える5.9カーネルから5.10カーネルへのいくつかの変更があるようです。私のデータ収集ソフトウェアで違いを確認できます。
私の平均ループ時間プログラム（連続的な読み書き呼び出しを実行するループ - そしてその間にいくつかの数学）：
私が見た最大時間は、Linuxカーネル5.9以下の場合は約43マイクロ秒からLinuxカーネル5.10以上の場合は50ミリ秒に変更されました。どうやらこの問題を解決したいのですが、どのような変化によって問題が発生したのかわかりません。犯人が何であるか、GRUBブートローダでカーネルパラメータを変更して問題を解決できるかどうかを知っていますか？どんなアドバイスにも感謝します。ありがとうございます！
編集する：
DAC出力を更新するためにwrite systemコマンドを継続的に呼び出す最小の例を実装しました。
DAC書き込みコマンドは、少なくとも「get_user」を呼び出してユーザ空間からカーネルにデータを取り込み、「outw」を呼び出してDACレジスタにデータを書き込みます。
最小の例を実行すると、連続書き込みシステムコマンドが実行されており、50ミリ秒の遅延があることがわかります。
ただし、システムコマンドの作成間に1マイクロ秒の遅延を追加すると、50ミリ秒の遅延が消えます。ユーザー空間情報にアクセスしようとしたり、カーネルからデバイスに書き込んだりするのが問題になる可能性がありますか？
ユーザー空間にアクセスしてカーネルからデバイスにデータを書き込む間にカーネルが実行する操作を分析する方法はありますか？
ベストアンサー1
マイコンピュータでカーネルを更新すると、リアルタイムスレッドで同じ問題が発生しました。私にsysctl -w kernel.sched_rt_runtime_us=-1役立ちました。
これを破る変更は次のとおりです。RT_RUNTIME_SHAREはデフォルトで無効になっています。