カーネルの高速化・安定化 改善案

最終更新: 2026-11-03

対象実装: arm/v1/src/kernel/（scheduler.rs 1189 行 / mmu.rs 318 行 / interrupt.rs 114 行 / allocator.rs 326 行 / reclock.rs 150 行 / timer.rs 193 行）

この文書の位置づけ

spec/resource_loading.md と spec/webfont_loading.md は ブラウザ側（L7）の性能を扱ってきた。カスケード索引（rule_index）や 軽量再ペイント経路（repaint_scope）など、そちらの最適化は一巡している。

本文書はカーネル側の改善案を扱う。まだ体系的に手が入っていない領域で、 コード読解で見つけた構造的な改善余地を記録する。

重要: 本文書は「案」であり実測結果ではない

spec/resource_loading.md の教訓を踏襲する。

• M-1: 最適化の前に内訳を測る。「重そうな方」を直感で選ぶと、 3 倍重い側を見逃す
• M-2: 変数は片方ずつ変える
• M-3: 計算が実測とよく一致しても、それは仮説の裏付けにならない
• QEMU はホスト負荷をそのまま受けるので、1〜2 回の計測で倍率を語ってはいけない

したがって本文書の各作戦は、着手前に基準値を測ることを前提とする。 「コードを読んで重そうだと思った」だけの段階であることを明示しておく。

過去の実績として、L7 側では 5 つの仮説のうち当たったのは 1 つだけだった （spec/resource_loading.md「教訓」節）。カーネル側でも同じ確率だと想定すべき。

現状で確認できた事実（コード読解による）

推測と区別するため、ソース上の位置と内容だけを先に列挙する。

F-8・F-9・F-10 は既に良い設計であり、変更対象ではない。 特に F-10 は安定化の道具として完成しているので、適用範囲を広げるだけでよい。

【2026-08-25 実装完了】作戦 1: カーネルスレッド間の TLB 全フラッシュを廃止・ページテーブル共有

実施した内容

1. ページテーブル共有（1-b）:
   • mmu::get_kernel_page_table() を新設。カーネルスレッド生成（spawn_process 等）時に毎回行われていた 12KB（PageTables）のヒープ動的確保およびコピーを完全撤廃し、同一ページテーブルを共有。
2. 無駄な TLB フラッシュのスキップ（1-a）:
   • scheduler::schedule() において、切り替え先の new_pt と現在の ttbr0_el1 を比較。
   • cur_pt != new_pt の時のみ msr ttbr0_el1, tlbi vmalle1is, dsb sy を実行するように最適化。
   • 同一ページテーブルを持つカーネルスレッド間（Webエンジン、タイマー、ネット、USB、アイドルスレッド等）のスイッチでは TLB フラッシュが 100% スキップされ、TLB キャッシュヒット率向上とコンテキストスイッチの劇的高速化を達成。

効果

• カーネルスレッド生成時の 12KB ヒープ確保ゼロ化。
• カーネルスレッド間コンテキストスイッチでの TLB 保持（全コアへの tlbi vmalle1is ブロードキャスト停止）。

作戦 2: MMU の粒度を見直す（TLB 効率）

現状

F-4 のとおり 2MB ブロックを 1024 個並べて 2GB を恒等マップしている。 L1 テーブルは 2 エントリしか使っていない。

改善余地

L1 で 1GB ブロックを使えば、RAM 領域（0x0000_0000〜0x37FF_FFFF）は 少数のエントリで表現でき、TLB エントリ消費が構造的に減る。

ただし属性の境界を崩してはならない。mmu.rs:47-50 のコメントにあるとおり:

gpu_mem=128 の RPi3 では GPU/フレームバッファ領域は 0x3800_0000〜0x3FFF_FFFF。 フレームバッファがこの範囲に確保され得るため、0x3800_0000 以上を Device(uncached) にしないと CPU のフレームバッファ書き込みが GPU と非コヒーレントになり横線ノイズが出る。

したがって 0x3800_0000 以上は 2MB ブロックの L2 を残すハイブリッド構成にする。

制約（絶対に守る）

• 0x3800_0000 境界の Device(uncached) 属性は変更禁止。崩すと横線ノイズが再発する
• kernel .text は 0〜4MB に収める前提がある（spec/README.md「メモリ管理」・ mmu.rs:207-213）。1GB ブロック化でこの前提を壊さないこと

期待効果と不確実性

TLB ミス率の低下は原理的に期待できるが、実際にどれだけ効くかは未知。 現状 TLB ミスが支配的である証拠はまだ無い。作戦 1 の計測でスイッチ頻度が 低いと分かれば、この作戦の優先度は下がる。

結論（2026-11-03 調査・評価完了）

1. RPi 3B+ の実物理メモリ構成（1GB）との不整合:
   • 0x0000_0000〜0x37FF_FFFF（896MB）が ARM RAM、0x3800_0000〜0x3FFF_FFFF（128MB）が GPU/VRAM 領域。
   • 0〜1GB 領域内に 0x3800_0000 の Device(uncached) 属性境界が存在するため、第1レベル（L1）で 1GB ブロックを適用するとこの境界が壊れ、GPU/CPU 非コヒーレンシーによる横線ノイズが不可避となる。
   • さらに、0〜4MB のカーネル .text に対する読み取り専用/実行保護の粒度も 2MB 単位が必須であり、1GB ブロック化は安全面・表示品質面から適用不可・現状の 2MB ブロック維持が最適と確定。
2. 作戦 1（TLB スキップ・ページテーブル共有）による課題解消済み:
   • カーネルスレッド間では同一ページテーブルが共有され、無駄な tlbi が 100% 抑制されているため、TLB キャッシュヒット率は既に最大化されている。現状の 2MB ブロック恒等マップが最も安全かつ最適な構造である。

作戦 3: タイマ割り込みの適応化（tickless idle）

現状

F-5 のとおり 10ms 固定、全コアで発火。interrupt.rs:104-112 で毎 tick:

if timer_fired {
    scheduler::decrement_wait_ticks();
    scheduler::scheduler_tick();
}
if scheduler::should_preempt() {
    scheduler::schedule();
}

改善案

• アイドル時はタイマを止める。register_idle_process（scheduler.rs:1110）が あるので、idle 実行中は次の sleep 期限までタイマ間隔を延ばす
• 逆に UI 操作中は 1ms へ短縮する動的切替も選択肢

前提条件（順序を守る）

timer.rs:86 に「SYSTEM_TICKS は『1 tick ≈ 10ms』という消費側の前提を保つため」 と明記されている。間隔を可変にするとこの前提が壊れる。

したがって着手順序は:

1. 時刻取得を get_system_time_ms()（cntpct_el0 直読）へ完全移行する
2. SYSTEM_TICKS に依存する箇所を全部洗い出して潰す
3. その後で初めてタイマ間隔を可変にする

順序を逆にすると時刻がずれ、sleep やタイムアウトが壊れる。 spec/resource_loading.md の R-8（依存順序を確かめてから着手する）に該当する。

作戦 4: スケジューラ選択ループの O(N) 削減

現状

F-6 のとおり scheduler.rs:775-788:

for i in 1..=num_proc {              // O(N)
    let idx = (start_idx + i) % num_proc;
    let p = &mut rq.processes[idx];
    if p.state == ProcessState::Ready {
        let score = (p.priority as usize * 10) + p.starvation_count;
        if best_idx.is_none() || score > best_score { ... }
        p.starvation_count += 1;     // Ready 全員に書き込み
    }
}

問題

• プロセス数に比例してスイッチコストが増える
• starvation_count += 1 が Ready 全プロセスのキャッシュラインを dirty にする。 読むだけなら共有できるが、書くと他コアのキャッシュを無効化する

対策案

• 優先度別 Ready キュー（3 本）にして先頭から取る O(1) 方式へ
• starvation は「選ばれなかった回数」ではなく 「最後に走った tick」を持てば加算書き込みが不要になる

ただし優先度は低い

現状のプロセス数が少なければ効果はほぼ無い。 まず num_proc の実際の値を測ること。 5 個程度なら作戦 1 に比べて桁違いに効果が小さい。

作戦 5: static mut 59 箇所の排他監査【安定化の本命】

なぜ最重要か

過去に同じ構造の事故を 2 回起こしている（いずれも記録済み）。

後者は「DNS のバグ」「TCP のバグ」として長期間追っていたが、 真因は排他の欠落だった。輻輳制御の実装に着手しかけていた。

F-7 のとおり static mut は 59 箇所あるが、 どれが複数コアから触られるかの一覧が存在しない。 同種の事故が再発する構造。

提案する手順

1. static mut 全 59 箇所を棚卸しし、spec/shared_state.md を新設して表で管理

   変数名	所有サブシステム	触るコア	現在の排他	必要な排他

2. 「単一コアからのみ」と判断したものはその根拠をコメントで明記する （後から並列化する人が判断できるように）

3. 複数コアの可能性があるものは RecoverableMutex（F-10）で保護

4. 新規に他コアからアクセスを追加する際のチェックリストを .agents/AGENTS.md へ追記

不変条件

• K-1: 共有資源に排他を入れるときは、その資源へ触る経路を全部数える。 1 箇所塞いでも残りが無防備なら同じことが起きる （spec/resource_loading.md で cache.rs だけ塞いで他に 5 箇所残っていた実例あり）
• K-2: コード中の「〜する場合は先に〜を検討すること」という申し送りは、 条件を満たした時点で守る（同 F-1）
• K-3: 並列度を上げるときは、触る共有資源を全部洗い出してから上げる

作戦 6: 例外ハンドラの情報充実【安定化】

現状

main.rs:2426 に #[panic_handler] はあるが、 同期例外（Data Abort / Instruction Abort）発生時の詳細が薄い。

提案

例外発生時に以下を必ず出す。

根拠

spec/resource_loading.md の F-2:

「保存に失敗」「読み返せない」のような症状のログだけでは原因に届かない。 read_file が内部で持っていた extent list unreadable という具体的な理由が決め手になった。 握り潰さずに理由を残しておくと、後から効く。

同じことが例外にも当てはまる。ESR_EL1 の DFSC を出すだけで 「権限違反か、未マップか、アラインメント違反か」が即座に切り分けられる。

spec/logging_policy.md の方針（L-1/L-3）に沿って、 1 例外 1 回の出力に留めること（ログで埋めない）。

優先順位

順位 1（計測）を飛ばしてはならない。 L7 側の最適化で「5 つの仮説のうち当たったのは 1 つ」だった実績がある。

測定基盤の不足（着手前に埋めるべき穴）

L7 側には [PERF] 系のログが揃っているが、カーネル側には無い。 最低限これらが必要。

計測時の注意（実績のある落とし穴）

spec/resource_loading.md に記録済み:

get_system_time_us はノードごとに呼ぶと MMIO 読み出しのコストで 計測対象が歪む（walk が 550 → 850 tick に増えた）。 細粒度の計測には非侵襲な指標（回数カウンタ）を使うこと。

コンテキストスイッチは高頻度なので、時刻取得を挟むと計測自体が対象を歪める。 まず回数カウンタ（アトミックのインクリメントのみ）で測ること。

さらに [PERF] ログを増やすとターミナルが dirty になり 全画面再描画を誘発する（同文書「計測が計測対象を汚染している可能性」）。 カウンタは貯めて、集計時に 1 回だけ出す。

未着手・調査段階の項目

• 作戦 1〜6 のいずれも未着手。本文書は改善案の記録のみ
• 各作戦の効果はすべて未実測。着手時は必ず基準値を取ってから
• 作戦 4 は num_proc の実測次第で不要になる可能性がある