Repository navigation
perf: prewarm migration-speed profiling off the checkpoint critical path - #76
Merged
Merged
Conversation
ElasticKernel を GPU 対応させるための先行研究調査レポート。 deep-research（5観点・21一次資料・97主張→25検証/全会一致）の成果。 GPU常駐テンソルのシリアライズ(Kishu/Fastensor)、GPUプロセスCR (cuda-checkpoint/CRIUgpu/CRAC/Singularity)、DLジョブCR(CheckFreq/ DataStates-LLM)、保存vs再計算(Checkmate他)を ElasticNotebook の migrate-vs-recompute コストモデルへの組み込みに関連づけて整理。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015g3MrF9eeuyi6dcnLyAhJc
ディスク速度の計測(profile_migration_speed)を最初の checkpoint() 内で同期実行 していたため、計測の実ディスク I/O が保存のクリティカルパスに乗っていた。 カーネル起動直後に prewarm_migration_speed() をバックグラウンド(daemon スレッド) で走らせ、結果をキャッシュするようにした。checkpoint() は進行中のスレッドを join して結果を使うだけになり、明示保存時には計測がパスから外れる。プリウォーム が無い/失敗した場合は従来どおり同期計測にフォールバックする。 ElasticHub の zero-reload 運用では「起動→待機」の間に計測が完了するため、最初の 明示保存 API 呼び出し時には migration speed がキャッシュ済みになる。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KS7ehdxC7BpzJYQtueU7kf
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
背景・課題
checkpoint 時のディスク速度計測 (
profile_migration_speed) は、これまで最初のcheckpoint()の中で同期実行されていた。計測は ~8MB のテストデータの write+read を伴う実ディスク I/O のため、その時間が保存のクリティカルパスに乗ってしまう。特に ElasticHub の zero-reload マイグレーションでは「明示 API で保存」するため、最初の明示保存呼び出しのレイテンシに計測コストが上乗せされていた。
変更内容
ディスク速度計測を**カーネル起動時にバックグラウンドで先回り実行（プリウォーム）**する方式に変更した。
ElasticNotebook.prewarm_migration_speed(dirname): バックグラウンドスレッドで計測を実行し結果をキャッシュ。manual_migration_speed指定時・計測済み・計測中はいずれも no-op（多重起動しない）。threading.Lockで保護。checkpoint(): 自前で計測する代わりに、進行中のプリウォームスレッドをjoin()して結果を使う。プリウォームが無い／失敗した場合のみ従来どおり同期計測にフォールバックする（挙動の後退なし）。elastic_kernel/kernel.py):ElasticNotebook生成成功直後にプリウォームを起動。計測先ディレクトリ (log_file_dir) は起動時点で確定・作成済み。計測先ディレクトリやセッション中に一度だけ計測する（結果をキャッシュ再利用する）という既存の性質はそのまま維持している。
スレッドで効く理由 / daemon の意味
計測の中身は ~8MB の pickle write + read というI/O バウンドな処理。Python には GIL があり複数スレッドが同時に Python バイトコードを実行することはできないが、ファイル I/O の syscall 中は GIL が解放されるため、計測スレッドのディスク待ちとメインスレッド（セル実行・待機）の処理は実際にオーバーラップする。CPU 並列化が目的ではなく「I/O 待ちを別スレッドへ逃がす」用途なので、GIL 下でも効果がある。
スレッドは
daemon=Trueで起動している。これはメインのカーネルプロセスが終了する際、計測の完了を待たずにこのスレッドを終わらせてよいようにするため。計測は補助処理（失敗しても同期計測にフォールバックできる）なので、シャットダウンをブロックさせない。効果
ElasticHub の zero-reload 運用では「起動→待機」の間に計測が完了するため、最初の明示保存 API 呼び出し時には migration speed がキャッシュ済みになり、計測 I/O が保存パスから外れる。
検証
black/isort/flake8/mypy: クリーンpytest: 97 passed, 16 skipped（回帰なし）🤖 Generated with Claude Code