自動運転カメラの高負荷、その原因はLinuxカーネルのどこに？
はじめに Turing株式会社ソフトウェアエンジニアの堀ノ内です！ 私が所属する自動運転チームでは2024 ~ 2025年に発売予定の自動車に搭載する自動運転システムの開発を行っています。Turingでは車両前方に取り付けられたカメラの画像を入力とし、機械学習モデルが進むべき経路を推論、その経路に沿って実際に車両を動かすための制御信号(ステアリング、アクセル、ブレーキ)をCANで車両に送信することで以下の画像のような自動運転を実現しています。 今回のブログでは以下について記載し、私達のチームの仕事内容について知って頂くきっかけになればと思います。 Turingの自動運転システムの紹介 GMSLカメラの評価と発生した問題 Linuxカーネル及びドライバのデバッグ Turingの自動運転システム Turingでは「カメラ画像入力 → 機械学習モデルで経路を推論 → 車両制御」の流れを実現するた
システムコールトレーシング: 吸い込まれる標準入力を観察する - にゃみかんてっくろぐ
Linuxその2 Advent Calendar 2020 18 日目の記事です。 「スクリプト書いてたんですが、なぜか途中で止まるんです」と言われた。 止まっている様子（シンタックスハイライトが綺麗でないので画像で） 確かに yarn gen で止まっている。 yarn start も date も実行されていない。終了コードは 0 で、正常だ。 「ファイルとして実行してみて」と伝えた。 最後まで実行される様子 最後まで実行された。 雰囲気で「たぶん 標準入力が吸い込まれている」と雑返答をしてしまったが、ここでその正体を明らかにしておきたい。 1. strace でシステムコールを記録する 2. システムコールから挙動を観察する 2-1. ヒアドキュメントの書き出し 2-2. 標準入力をヒアドキュメントに差し替え 2-3. bash を実行 2-4. 標準入力を読み込み 2-5. dat
Linuxカーネルの起動時トレースの話 - Qiita
カーネル起動時トレース Linuxカーネルの起動処理は、様々なことが行われるのにそれをデバッグする方法はprintkだったり、逆にkgdbを外部デバッガから繋いだりと、結構な手間がかかっていました。カーネルが起動してしまえば、ftraceにperf, BPF, systemtapと複数の手段が使えるのに、起動時のデバッグは細かいことが出来ません。これは、起動時に指定できるオプションが大雑把になるのが大きな理由の一つでした。シェル芸ではないですが、1行プログラミングだけで様々なことをするのは大変です。 そこで導入されたのがExtra Boot Configuration (bootconfig)です。Bootconfigについては前回の記事を参考にしてください。 ここではカーネルコマンドラインのトレースオプションと、Bootconfigによって拡張されたBoot-time trace（CON
Linuxカーネルをgdbでデバッグ（またはディストリビューションのカーネルを使うときは当たってるパッチにも注意しよう） - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
この記事はLinux Advent Calendar 2018の1日目ですΣ(ﾟ∀ﾟﾉ)ﾉｷｬｰ イントロ ほんとは別の内容にしようと思ってたのですが、進めてる途中でカーネルのデバッグをするハメになったのでカーネルデバッグをネタにしてみました。カーネルのデバッグと言っても普通のデバッグと変わらないよね〜というところがわかると思います。（｀・ω・´)<ｺﾜｸﾅｲﾖｰ デバッグの環境としてはlibvirt(qemu)で動いてるゲスト環境にホスト側からgdbでデバッグする感じです。ディストリビューションはFedora 29です。デバッグするカーネルはFedoraのカーネルで4.19.2-300.fc29.x86_64です。 テストコード テストコードは↓です。これはdebugfsのディレクトリ（大概は/sys/kernel/debug/だと思います）にopen-testってファイルを作って、その
ftraceの仕組みとアーキテクチャ
はじめにじっくりとライトブーストの仕事をする予定だったのに, ライトブーストのテストにはsystemtapを使いたいなぁとか妄想してたら, 気づいたらftraceについて調べていたので一段落ということでメモっておく. 参考資料としては, “Linuxカーネル Hacks"の8章と, カーネルのソースコードと, ネット上に転がっている文書もろもろ. 理解した内容については, Twitterで散々つぶやくも片っ端から無視されてしまったので, 完全に独断によるものだから(想像も多く含まれる), 正しいかどうか分からないが, 誤っていたら/補足があれば, 今度こそTwitterで指摘して. 色々調べてしまったので, 検討の結果, いくつかの記事に分離して書くことにした. 2-3個になると思う. ftraceの基本原理ftraceの仕事は, 名前の示すとおり, 関数単位である. 関数単位で, 「それ
Ftraceでカーネルの一部の処理を追いかける方法 - Qiita
ftraceのfunctionトレーサやfunction graphトレーサを使うと、カーネルの関数呼び出し処理を追いかけることができます。 ftraceの諸機能をカーネルで有効にする方法については前回の投稿を参照してください。ただし今回書いている内容は、恐らくFedoraやUbuntuのカーネルではデフォルトで有効になっています。 関数コールトレーサ ftraceにはLinuxカーネル内の関数呼び出しをトレースする関数コールトレーサ・関数コールグラフトレーサをサポートしています。 関数コールトレーサはfunctionを、関数コールグラフトレーサは function_graph を、/sys/kerne/debug/tracing/current_tracerに書き込むだけで利用できます。 これらの関数コール（グラフ）トレーサは、インライン展開されていないすべての関数呼び出しをトレースし、
LinuxカーネルHack: 1ヶ月の活動の振り返りとこれからの展望 - 佐野デジタル研究所
Linuxカーネルの探索をはじめて1ヶ月が経過したので、今回はその振り返り。こうやってまとめてみると、1ヶ月あれば結構いろいろできるなぁと思った。 やったこと ビルド UMLカーネル UML(User Mode Linux)を使うことで、GDBを使いながらカーネルを効率よく解析できるようになった。最近のトレンドは、KVM(Kernel-based Virtual Machine)になりつつあるので、KVMを試したいけど、手元のマシンではIntel VT未対応で断念。 UMLによるはじめてのLinuxカーネルHack カーネルビルドの高速化 カーネルをいじりだすと、何度もカーネルをビルドすることになるので、ビルド時間はできるだけ短縮しておきたい、ということで実験した。最近はカーネルをビルドする時はmake -j 3でやってる。 LinuxカーネルHack: ビルド時間の短縮を求めて 特定ファ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Using RCU’s CPU Stall Detector — The Linux Kernel documentation
SystemTapの使い方 - Qiita