linuxシステムCPU負荷が高いためcameraが失われてフレームが失われる検索プロセス
問題の背景
cameraアプリケーションの作成は、アプリケーション層がbufをタイムリーに取得しなかったり、カーネルのbufを長期にわたって占有してカーネルキューに返さなかったりすると、フレームが失われることを知っているはずです.このフレームロスは、カーネル駆動フレームが知られているように、本来DMAの宛先アドレスを再設定すべきであるが、キューに空きbufがないため、以前の画像コンテンツを上書きするフレームロスである.この情報はアプリケーション空間にフィードバックすることができる.
以上のシナリオはcameraの関連カーネル割り込みでカウント統計可能であるが,本稿ではcamera割り込みを直接失ったフレームを検討する,すなわちこの場合,割り込みカウントもフレームを失った場合があるかどうかを確認することはできないが,我々のプロジェクトのニーズははっきりしないフレームを失ってはならない,アプリケーションが画像をタイムリーに処理せずに画像コンテンツが上書きされることを可能にするが、システムが何も知らずに画像データを失うことはできない.次に、プロセス全体がどうなっているかを見てみましょう.
問題を発見する
カメラが撮影した画像の内容をプレビューするのは、肉眼だけではフレームを失うかどうかを発見するのは難しいが、どうやってこのフレームを失う操作があることを発見したのだろうか.
撮影内容の特殊性のため、私達はフレームごとに撮影した内容がすべて異なっていることを保証することができて、しかも規則的に従うことができて、私達はこのような前提の下で、時には画像の内容が一貫していないことを発見して、しかしシステムはいかなるフィードバックがありません(例えばフレームをなくして、処理を中断する時相応の情報があります)、システムに情報提示がないが,画像内容が一貫していない場合,受信側に論理エラーがあるかどうか疑問である.
この問題では、我々のシステムはMCUと組み合わせて使用されており、sensorはSTROBE出力、すなわちsensorが露光されるとSTROBEがハイレベルに出力され、他の場合はローレベルになるように構成されており、MCUはこの信号を検出し、対応するカウントを行う.同時に、camera割り込みでは、SOCの1つのpinを反転操作し、フレームヘッダ割り込みはpinを高くし、フレーム終了割り込みはpinを低くし、このようにして、SOCにもフレーム信号出力があります.これにより、オシロスコープを使用してsensorのSTROBEフレーム信号に接続し、SOCの割り込みpin信号に接続し、アプリケーションを実行し、オシロスコープは2つの信号が1つに対応しているかどうかを確認し、場合によってはSOC pinの反転が1回少なくなった場合、受信側に問題が発生したことを確認することができます.
実験の結果,画像内容が一貫していない場合,SOC pin反転が1回少なくなるとともに,mipiのいくつかの相関レジスタを通過し,mipiコントローラはこのフレームを受信し,mipi状態相関レジスタはエラーを報告していない,すなわちこのフレームの画像データは完全であるが,データ通路全体でcameraの割り込みが失われることが分かった.最終的にフレームを失う現象を引き起こす.
問題を分析する
現象的には、SOCはフレームコンテンツを受信しているが、最後のcamera割り込みでは表現されず、このような場合、CPU負荷は比較的高いが、CPU負荷が低い場合、問題は検出されない.同時にsensor出力のフレームレートを相応に低下させると、問題が発生する確率が大幅に減少する.以上の状況に基づいて、以下の可能性を判断しました. camera駆動フレームワークに問題があり、高フレームレートで高負荷の場合、処理が不適切で損失中断を招く. CPU負荷が高い場合、一部のアプリケーションで使用されるドライバに長時間のシャットダウン割り込みがある可能性があり、camera側の割り込みに応答できない. CPU負荷が高く、一部のスレッド、カーネル駆動などのスケジューリングがタイムリーではなく、新しいフレーム画像の割り込みがまた到来し、それによって前の割り込みをカバーし、現象は損失割り込みである.
位置決めの問題
上記の分析判断に基づいて、以下のテスト実験を行いました.は、他の駆動であるかどうかについて、全体的な割り込みをオフにし、他の割り込みに応答しなかった.我々の実験操作は以下の通りである:システム内の他の外付け機器を閉じ、使用しないで、システムの他の外付け機器の中断を減らして、応用運行のこの過程で、少数の駆動中断実行だけがあって、長い間システムの中断がないことを確保する.実験テストでは,他の周辺機器を用いなくても,システムの他の割り込みを低減しても,camera割り込みが失われる場合があることが分かったので,全割り込みを閉じてcamera割り込みを失う可能性を排除した. システムアプリケーションスレッドの親核性を設定します.アプリケーション運転中、各CPUの占有率を測定し、CPU 0の占有率が高い場合があるか確認します.ARMは一般的にCPU 0応答システムirqによって中断されるため、CPU 0の占有率が高いと、適時に処理できず、紛失中断を招く場合がある.システムでCPUを比較消費するスレッドを は、camera関連割り込み応答を他のコアに移行する.
問題を解決する
割り込み処理の問題については、linuxシステムでは、アプリケーションがCPU 0に走っていると、欠ページ割り込み異常が発生するが、停止割り込みはなく、欠ページ異常優先度がirq異常より高く、一定の影響があるが、影響は大きくないことが分かった.また、上記のいくつかのテスト結果に基づいて、比較的CPUを消費するスレッドをCPU 0以外のコアに移行して実行し、後続のテストで紛失中断が発見された場合、スレッド親核性+移行中断応答を設定する方法を考慮して処理する.スレッドの親核性の設定については、
最後に、もし本文があなたに役に立つならば、関心を歓迎して、いいねをつけて、コレクションして、分かち合って、支持に感謝します!
cameraアプリケーションの作成は、アプリケーション層がbufをタイムリーに取得しなかったり、カーネルのbufを長期にわたって占有してカーネルキューに返さなかったりすると、フレームが失われることを知っているはずです.このフレームロスは、カーネル駆動フレームが知られているように、本来DMAの宛先アドレスを再設定すべきであるが、キューに空きbufがないため、以前の画像コンテンツを上書きするフレームロスである.この情報はアプリケーション空間にフィードバックすることができる.
以上のシナリオはcameraの関連カーネル割り込みでカウント統計可能であるが,本稿ではcamera割り込みを直接失ったフレームを検討する,すなわちこの場合,割り込みカウントもフレームを失った場合があるかどうかを確認することはできないが,我々のプロジェクトのニーズははっきりしないフレームを失ってはならない,アプリケーションが画像をタイムリーに処理せずに画像コンテンツが上書きされることを可能にするが、システムが何も知らずに画像データを失うことはできない.次に、プロセス全体がどうなっているかを見てみましょう.
問題を発見する
カメラが撮影した画像の内容をプレビューするのは、肉眼だけではフレームを失うかどうかを発見するのは難しいが、どうやってこのフレームを失う操作があることを発見したのだろうか.
撮影内容の特殊性のため、私達はフレームごとに撮影した内容がすべて異なっていることを保証することができて、しかも規則的に従うことができて、私達はこのような前提の下で、時には画像の内容が一貫していないことを発見して、しかしシステムはいかなるフィードバックがありません(例えばフレームをなくして、処理を中断する時相応の情報があります)、システムに情報提示がないが,画像内容が一貫していない場合,受信側に論理エラーがあるかどうか疑問である.
この問題では、我々のシステムはMCUと組み合わせて使用されており、sensorはSTROBE出力、すなわちsensorが露光されるとSTROBEがハイレベルに出力され、他の場合はローレベルになるように構成されており、MCUはこの信号を検出し、対応するカウントを行う.同時に、camera割り込みでは、SOCの1つのpinを反転操作し、フレームヘッダ割り込みはpinを高くし、フレーム終了割り込みはpinを低くし、このようにして、SOCにもフレーム信号出力があります.これにより、オシロスコープを使用してsensorのSTROBEフレーム信号に接続し、SOCの割り込みpin信号に接続し、アプリケーションを実行し、オシロスコープは2つの信号が1つに対応しているかどうかを確認し、場合によってはSOC pinの反転が1回少なくなった場合、受信側に問題が発生したことを確認することができます.
実験の結果,画像内容が一貫していない場合,SOC pin反転が1回少なくなるとともに,mipiのいくつかの相関レジスタを通過し,mipiコントローラはこのフレームを受信し,mipi状態相関レジスタはエラーを報告していない,すなわちこのフレームの画像データは完全であるが,データ通路全体でcameraの割り込みが失われることが分かった.最終的にフレームを失う現象を引き起こす.
問題を分析する
現象的には、SOCはフレームコンテンツを受信しているが、最後のcamera割り込みでは表現されず、このような場合、CPU負荷は比較的高いが、CPU負荷が低い場合、問題は検出されない.同時にsensor出力のフレームレートを相応に低下させると、問題が発生する確率が大幅に減少する.以上の状況に基づいて、以下の可能性を判断しました.
位置決めの問題
上記の分析判断に基づいて、以下のテスト実験を行いました.
sched_setaffinity()関数で親核性を設定し、CPU 0以外のコア運転に移行し、CPU 0がタイムリーな応答中断を保証する.実験的試験により,部分スレッドの親核性を設定した後,システムにcamera中断が失われることはなかった.したがって,CPU 0の占有率が高いため,割り込みにタイムリーに応答できず,camera割り込みが失われる場合があると推定する.echo 2 > /proc/irq/CAMERA_IRQ/smp_affinityによりcameraの相関割り込み応答をCPU 1に移行し、その後、アプリケーションテストを行う.これにより、他の駆動割り込みがCPU 0の割り込みを閉じることによるフレーム損失が排除され、このような場合においても損失割り込みの問題がある場合には、camera駆動をチェックし、論理的な脆弱性があるか否かを確認し、割り込みを招くことになる.実験テストでは,この実験は中断をなくすことはなかったことが分かった.問題を解決する
割り込み処理の問題については、linuxシステムでは、アプリケーションがCPU 0に走っていると、欠ページ割り込み異常が発生するが、停止割り込みはなく、欠ページ異常優先度がirq異常より高く、一定の影響があるが、影響は大きくないことが分かった.また、上記のいくつかのテスト結果に基づいて、比較的CPUを消費するスレッドをCPU 0以外のコアに移行して実行し、後続のテストで紛失中断が発見された場合、スレッド親核性+移行中断応答を設定する方法を考慮して処理する.スレッドの親核性の設定については、
cat /proc/PID/statusでCpus_を表示できます.allowed_List:1-3情報は、設定が有効であるかどうかを確認し、上記情報は、このスレッドがCPU 1~3で実行されていることを意味する.一方、割り込みがどのコアによって応答されたかを確認すると、cat /proc/interruptsが対応する情報を取得することができる.最後に、もし本文があなたに役に立つならば、関心を歓迎して、いいねをつけて、コレクションして、分かち合って、支持に感謝します!