メモリ確保のために37GBもスキャンするとかワロタｗ そんなん全プロセス止まるに決まってるだろｗｗｗ カーネルの挙動とか沼すぎて草も生えん。
リアルタイム性を求めるシステムでスワップアウトを許容するデザインなのがチャレンジングに見える。でも自動運転だと無茶苦茶メモリ使いそうだし仕方ないのかな/運転データ収集システムを分離するとか
ログを書いて行くだけで使う予定のないファイルキャッシュを粛々と作り続けてしまうというところが根本かな。リストをゾーン別に分ける必要もありそう。／1000万件連結リストスキャンを37GBスキャンと呼ぶのは誤解の元
組込環境の運転データ収集システムなのに、富豪的にメモリの確保・解放を繰り返す設計が根源的な落ち度だよな。カーネルには非がないと思う。システムの設計ミスを直すべきでカーネルチューンで逃げるべきではない例
改善するならカーネルではなく、アプリケーションの設計だと思うけど。技術的興味でカーネル追ってるのかな？それであればいいけど、よくわからん。
この手のリアルタイム性が求められるシステムでDockerみたいなレイヤーを挟むのって余計なトラブルを増やさんか？と思わんでもない(組み込み系はやったこと無いが)
継続的にデータを生成・収集する場合、リングバッファを経由してファイルに書き込むことでメモリ消費を抑えるものだと思うのだが私が何か読み落としているのだろうか…？
制御系にはコンピュータの面白さが詰まってて好き。
全プロセスが一秒止まる不具合続編: カーネル内部で何が起きたか？
メモリ確保のために37GBもスキャンするとかワロタｗ そんなん全プロセス止まるに決まってるだろｗｗｗ カーネルの挙動とか沼すぎて草も生えん。
リアルタイム性を求めるシステムでスワップアウトを許容するデザインなのがチャレンジングに見える。でも自動運転だと無茶苦茶メモリ使いそうだし仕方ないのかな/運転データ収集システムを分離するとか
ログを書いて行くだけで使う予定のないファイルキャッシュを粛々と作り続けてしまうというところが根本かな。リストをゾーン別に分ける必要もありそう。／1000万件連結リストスキャンを37GBスキャンと呼ぶのは誤解の元
組込環境の運転データ収集システムなのに、富豪的にメモリの確保・解放を繰り返す設計が根源的な落ち度だよな。カーネルには非がないと思う。システムの設計ミスを直すべきでカーネルチューンで逃げるべきではない例
改善するならカーネルではなく、アプリケーションの設計だと思うけど。技術的興味でカーネル追ってるのかな？それであればいいけど、よくわからん。
この手のリアルタイム性が求められるシステムでDockerみたいなレイヤーを挟むのって余計なトラブルを増やさんか？と思わんでもない(組み込み系はやったこと無いが)
継続的にデータを生成・収集する場合、リングバッファを経由してファイルに書き込むことでメモリ消費を抑えるものだと思うのだが私が何か読み落としているのだろうか…？
制御系にはコンピュータの面白さが詰まってて好き。