# GPUドライバトレーシング ## 定義 GPUドライバトレーシングは、GPU ドライバと Linux カーネルの境界で発生するジョブ投入・スケジューリング・メモリ管理・割り込み・表示同期を、トレースポイントや kprobe でイベントとして収集する手法である。 GPU カーネル内部のワープ実行やメモリアクセスを直接見るのではなく、ホスト側から GPU 活動の開始・完了・待ち・再配置を再構成する。(Source: [[@2025__eunomia.dev__eBPF Tutorial by Example - Monitoring GPU Driver Activity with Kernel Tracepoints]]) ## 横断的知見 - **GPU 観測性の計装境界を、CUDA API 層と GPU 内部層の間にあるドライバ層として明示できる**: CUDA API の uprobe はアプリケーションからドライバへ作業を渡す入口を捉え、GPU ドライバトレーシングは DRM スケジューラや `nvidia.ko` のジョブ処理を捉え、eGPU は PTX 注入によって GPU 内部へ踏み込む。 3 層は粒度と移植性が異なるため、ドライバトレース単体を GPU 内部プロファイラとみなしてはならない。(Source: [[@2025__eunomia.dev__eBPF Tutorial by Example - Monitoring GPU Driver Activity with Kernel Tracepoints]], [[@2026__eunomia.dev__CUDA Events - eBPF-based CUDA API Tracing]], [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]], [[GPU観測性]]) - **ベンダー非依存性と詳細度はトレードオフになる**: DRM の `gpu_scheduler` トレースポイントは Intel・AMD・Nouveau にまたがる共通の監視入口を与える一方、i915・AMDGPU のメモリ管理や NVIDIA proprietary driver の内部関数を詳しく見るにはベンダー固有のイベント・プローブが必要になる。 NVIDIA では DRM 共通経路が使えず、`nvidia.ko` の関数名に依存するため、共通性より詳細度と環境依存性を引き受ける構成になる。(Source: [[@2025__eunomia.dev__eBPF Tutorial by Example - Monitoring GPU Driver Activity with Kernel Tracepoints]], [[GPU観測性]]) - **イベント駆動計装は、GPU 観測性で繰り返される「常時稼働と低侵襲性」の要求をドライバ層で実装する**: 周期的なポーリングでは短命ジョブを取りこぼすのに対し、トレースポイントはジョブ発生時だけ動作する。 ただし「ゼロオーバーヘッド」という宣伝文句は厳密にはイベントごとの追加コストを含まない表現であり、低オーバーヘッド性は対象カーネル・イベント頻度・出力方法を含む実環境で測定すべきである。(Source: [[@2025__eunomia.dev__eBPF Tutorial by Example - Monitoring GPU Driver Activity with Kernel Tracepoints]], [[GPU観測性]]) - **診断可能なボトルネックはドライバ境界の因果鎖に偏る**: DRM の依存待ち、i915 の shrink・ページフォールト、AMDGPU の VRAM/GTT 移動、NVIDIA の ioctl・mmap・Xid は、ジョブが遅い理由をホスト側の待ち・メモリ圧迫・エラーへ分解する。 しかし、同じ実行時間の増加がコアレッシング失敗、分岐発散、共有メモリバンク競合、ワープ占有率低下のどれに由来するかは、ドライバトレースからは決められない。(Source: [[@2025__eunomia.dev__eBPF Tutorial by Example - Monitoring GPU Driver Activity with Kernel Tracepoints]], [[GPU観測性]]) - **eBPF は観測対象を GPU へ拡張しても、フックの可搬性を自動では保証しない**: DRM の共通イベントは複数ベンダーへの展開を容易にするが、NVIDIA proprietary driver の kprobe は内部関数名の変更に影響される。 これは eBPF の verifier がプログラムの安全性を検査することと、対象ドライバのイベント・フィールドが版をまたいで互換であることが別問題であるという、既存の eBPF 可搬性の知見を GPU ドライバ層へ具体化する。(Source: [[@2025__eunomia.dev__eBPF Tutorial by Example - Monitoring GPU Driver Activity with Kernel Tracepoints]], [[eBPF]]) ## 未解決の問い - DRM スケジューラのジョブ ID と完了側の fence を、Intel・AMD・Nouveau の各実装で安定して対応づけ、正確な実行時間として検証できるか。 - NVIDIA の内部関数 kprobe に依存せず、proprietary driver でもジョブ・メモリ・割り込みを版横断で取得できる共通インターフェースは成立するか。 - ドライバトレース、CUDA API トレース、GPU 内部 PTX 計装を、フレームワークの順伝搬・逆伝搬・集団通信や個別リクエストへ損失なく帰属させる方法は何か。 - tracepoint と kprobe のイベント収集を常時有効にした場合、ゲーム・LLM 訓練・動画処理のイベント頻度別に許容できるオーバーヘッドはいくらか。 - NVIDIA スクリプトのようなサンプリングと、DRM スケジューラの全イベント収集を、診断精度とデータ量の観点からどう使い分けるべきか。 - 原文のスクリプト例にあるプローブ指定・未実装関数・ドライバ版依存を、自動検出して実行前に検証する CI や適合性テストをどう設計するか。 ## 関連 - ソース: [[@2025__eunomia.dev__eBPF Tutorial by Example - Monitoring GPU Driver Activity with Kernel Tracepoints]] / [[@2026__eunomia.dev__CUDA Events - eBPF-based CUDA API Tracing]] / [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]] - 概念: [[GPU観測性]] / [[eBPF]] / [[動的計装]] / [[GPU最適化]] / [[カーネル障害診断]] - エンティティ: [[eunomia-bpf]] / [[bpftime]] / [[bpftrace]] / [[Linux]] / [[Intel]] / [[AMD]] / [[NVIDIA]] - 関連 MOC: [[AI Infra Telemetry - MOC]] ## 出典 - [[@2025__eunomia.dev__eBPF Tutorial by Example - Monitoring GPU Driver Activity with Kernel Tracepoints]] — DRM スケジューラ、i915、AMDGPU、vblank、NVIDIA proprietary driver のトレース設計。 - [[@2026__eunomia.dev__CUDA Events - eBPF-based CUDA API Tracing]] — CUDA API 層の uprobe トレース。 - [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]] — GPU 内部への PTX 計装。