← 2026-04-08 の一覧へ戻るホーム
**RSoC 2026：Redox OS の新しい CPU スケジューラ**

2026/04/08 6:41

**RSoC 2026：Redox OS の新しい CPU スケジューラ**

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

Redox OS はレガシーの Round‑Robin スケジューラを Deficit Weighted Round‑Robin（DWRR）にアップグレードし、さらにインタリーブ版を追加しました。
DWRR では各キューに秒あたり 1、2、または 4 のトークンという重みが与えられ、プロセスはその残高がベース価格を下回るまで実行されます。単純な DWRR スキームは、高優先度のキューが CPU 時間を独占するため低優先度のキューを飢餓状態に陥れる可能性があります。
インタリーブ DWRR は、最高優先度キューのサイクル後に、下位優先度キューが実行できるだけのトークンを蓄積しているかどうかを確認し、その上でトップ優先度へ戻ることでこれを緩和します。 これにより遅延感度の高いタスクは保護されつつ、依然として高優先度作業が優遇されます。
シミュレーション: 16 コアで 40 000 個の CPU を大量に消費するタスクを想定した「理想化」ワークフローでは、RR は平均応答時間約 1 250 タック、単純 DWRR は約 34 460 タック（≈27 倍遅い）、インタリーブ DWRR は約 7 440 タックに減少しました。ランダム化されたタスクテスト（各コアで毎ティック新規タスクを生成、実行時間 2–100 000、ブロッキング確率最大 0.001）では平均が RR ≈51.9 タック、DWRR ≈3 572 タック、インタリーブ DWRR ≈309 タックでした。
実際のケース: Pixelcannon ゲームで FPS は RR の下で約 1 000（2 個の CPU を大量に消費するバックグラウンドタスクあり）から、フォアグラウンドタスクを優先したときに約 1 150 に上昇しました（15 % 増）。スケジューラ操作数は秒間 243 から 360 に (+48 %) 増加し、中位ウェイクアップ遅延も顕著に減少しました。
結論: インタリーブ DWRR は RR の公平性と DWRR の優先度パフォーマンスのバランスをうまく取っており、遅延感度の高いタスクを過剰な飢餓状態に陥れることなく保護します。これは Redox のデフォルトスケジューラ候補として有力であり、大量のバックグラウンドワークロードを実行するユーザーやリアルタイム・インタラクティブジョブを管理する管理者に恩恵をもたらすでしょう。

本文

Akshit Gaur 著 – 2026年4月2日（木）

TL;DR

Redox OS のラウンドロビンスケジューラを Deficit Weighted Round‑Robin (DWRR) に置き換え、プロセスに優先度を割り当てるようになりました。軽負荷時は差がほとんどありませんが、重負荷時には以下のような効果が確認できます。

指標RRDWRRInterleaved DWRR
FPS（pixelcannon）~0 %+15 %–
Ops/sec（schedrs）243360 (+48 %)–

1. 背景

1.1 ラウンドロビンスケジューラ

Redox OS は現在、シンプルな RR スケジューラを採用しています。各コアはサーキュラーキューから次の実行可能タスクを順番に取得します。
メリット: 公平性が高く、オーバーヘッドが低い。
デメリット: 優先度がないため、インタラクティブな I/O タスクは CPU 集中型のバックグラウンド作業に遅れを取ることがあります。

1.2 Deficit Weighted Round‑Robin (DWRR)

プロセスは複数の優先度付きキューに分けられます。コンテキストスイッチ時にスケジューラは以下を行います：

  1. 最も高い優先度のキューを選択。
  2. その重み（weight）を「デフェクト」カウンタへ加算。
  3. デフェクトがベースコストより小さくなるまでタスクを実行し、次のキューに移動。

これにより高優先度プロセスは速やかに処理されますが、低優先度プロセスは飢餓状態になる可能性があります。

1.3 Interleaved DWRR

飢餓を防ぐためにキューの処理を インタリーブ（交互）します。トップキューから1タスク実行した後、下位キューでデフェクトが十分なら1回実行し、その後再びトップキューへ戻ります。
これにより高優先度タスクの高速化を維持しつつ、低優先度キューにも一定時間 CPU を割り当てます。

2. 設定

  1. redox_syscall
    と 
    libredox
    を 
    recipes/core
    にクローン。
  2. make rp.renice
    でビルド、または 
    desktop.toml
    に 
    renice = {}
    を追加。
  3. テスト実行： 
    • nice -n -10 pixelcannon
    • renice -n -5 -p <pid>

3. シミュレーション結果

3.1 理想化ワークフロー（40 000 の長時間 CPU タスク）

スケジューラ平均応答時間
RR1249.5 タック
DWRR34 459.6 タック
Interleaved DWRR7442.5 タック

観察: 全体的には RR が最速ですが、DWRR は最高優先度のタスクで最大 27 倍まで応答時間を改善します。

3.2 ランダム化タスク（各コア毎ティックに新タスクが発生する確率）

スケジューラ平均応答時間
RR51.9 タック
DWRR3572.6 タック
Interleaved DWRR309.4 タック

観察: Interleaved DWRR は高優先度タスクの応答時間を劇的に短縮し、低優先度での飢餓も抑制します。

4. 実際のベンチマーク

4.1 pixelcannon（インタラクティブ FPS）

スケジューラFPS
RR~1000
DWRR（prio 0）~1000
DWRR（pixelcannon を高優先度、ハグを低優先度に設定）1150

結果: インタラクティブ応答性が 15 % 向上。

4.2 schedrs（純粋なスケジューリング）

指標RRDWRR
Ops/sec243360 (+48 %)
Median wake‑up latency–↓

結果: スケジューリングオーバーヘッドとレイテンシが大幅に削減。

5. 結論

  • DWRR は背景ノイズによる高優先度、レイテンシ感受性タスクの飢餓を防ぎます。
  • Interleaved DWRR は純粋な DWRR よりも大幅に低優先度での飢餓を抑えつつ、優先度ジョブの応答時間を高速化します。
  • 実機テストはシミュレーション結果と一致しています。

次のステップ: 静的キュー論理を全 EEVDF スケジューラの動的ラグ計算に置き換えること。

同じ日のほかのニュース

一覧に戻る →

2026/04/08 3:09

**プロジェクト・グラスウィング：AI時代における重要ソフトウェアの保護**

## Japanese Translation: Project Glasswingは、AWS、Microsoft、Google、Cisco、Apple、Broadcom、JPMorgan Chase、NVIDIA、Palo Alto Networks、およびLinux Foundationを含む主要なクラウド・ソフトウェア・金融企業を結集し、Anthropicの未公開Claude Mythos Preview AIを用いて高重大性のソフトウェア脆弱性を発見・修正することを目的としています。Mythos PreviewはすでにOpenBSD、FFmpeg、およびLinuxカーネルで重要なバグを検出し、その後メンテナがパッチを適用しました。Anthropicはパートナー向けに最大1億ドルの使用クレジットと、オープンソースセキュリティグループへの追加400万ドルの寄付を提供しており、40社以上の組織もモデルアクセスを受け取ります。参加者は90日以内に調査結果を公開し、ベストプラクティスを共有し、脆弱性開示、自動パッチング、安全な開発ライフサイクル、およびサプライチェーンセキュリティに関する推奨事項を策定する予定です。このイニシアチブは米国政府担当者と協力してツールの攻撃および防御機能を評価し、最終的には独立した組織が業界・公共部門全体で継続的な大規模サイバーセキュリティ作業を調整する可能性があります。研究プレビュー後、AnthropicはMythos PreviewをClaude API、Amazon Bedrock、Google Vertex AI、およびMicrosoft Foundry経由で参加者に対し1百万トークンあたり25ドル／125ドルで提供する予定です。

2026/04/08 0:03

「月のフライバイ」

## Japanese Translation: オリオン宇宙船は、NASA のアーテミス II ミッションに乗組みされ、2026年4月6日に月を周回しながら一連の写真を撮影しました。クルー（パイロット・ビクター・グローバー、指揮官リード・ウィスメン、ミッションスペシャリストジェレミー・ハーネスとクリスティーナ・コック（さらにカナダ宇宙機関のアストロノート・ハーネス））はオリオンの窓から、EDT 18:41に地球沈没、ET 19:22に地球昇起、および月面の詳細な映像を記録しました。1枚の画像ではオリオンの前景から月と地球の両方が同時に写っており、別のクローズアップは周回の終盤（約3:41）に撮影されました。ハーネスは観測期間中に窓2にカメラシャードを装着し、いくつかのショットでは日食時に太陽が月面を背光し、左端で太陽が昇り、ほぼ1時間続いたシーケンスの終わりまで撮影されました。午後2:19には画像の左半分が月表面で満たされました。オリオン自体は複数の写真で日光を浴び、その輪郭が宇宙空間に浮かぶ姿が際立っています。 この改訂された要約は、将来の設計への影響について推測的な結論を避けつつ、すべての主要ポイントを網羅しています。

2026/04/08 4:44

S3ファイル

## Japanese Translation: Andy Warfield のチームは **S3 Files** を構築しました。これは、ユーザーが Amazon S3 バケットまたはプレフィックスを EC2、コンテナ、または Lambda 上の NFS スタイルネットワークファイルシステムとしてマウントできるシステムです。この設計では EFS がステージングに使用されます。ファイル変更はローカルで書き込まれ、その後約 60 秒ごとに自動的に S3 に *コミット* されます（起動時には手動コミット制御はありません）。複数のクライアントが同じオブジェクトを修正した場合、conflict‑resolved コピーが lost+found ディレクトリに保持されます。メタデータは遅延でハイドレーションされ、小さなファイルは即時ロードされ、大きなファイルは読み込み時にストリーミングされるため、数百万オブジェクトを持つバケットでも迅速にマウントできます。大規模な連続読み取りはローカルキャッシュをバイパスし、並列 GET を介して直接 S3 にアクセスすることで、クライアントあたり約 3 GB/s の速度を実現し、多数のクライアントにわたって拡張可能です。システムは S3 の IAM ポリシー、オブジェクトの不可変性、および命名セマンティクスを保持しつつ、完全な NFS スタイルファイル操作（パーミッション、原子リネーム、ディレクトリトラバーサル）を公開します。ただし、S3 にはネイティブなリネームがないため、リネーム操作は高コストであり、有効な POSIX ファイル名にマッピングできないキーはマウントから除外されます。 Warfield の以前の **S3 Tables** と **S3 Vectors** に関する研究は、構造化データ・ベクトル・ファイルを S3 で一等のプリミティブとして扱うというより広範な戦略を示しています。UBC でのゲノム研究では、大規模データセットをローカルファイルシステムとオブジェクトストア間で移動する際の苦労が明らかになり、この統一アクセスレイヤーへの動機付けとなりました。ベータ版からの早期フィードバックは、パフォーマンス制限（例：5,000 万オブジェクトを超えるマウントに対する警告）、コミットウィンドウ、および問題キーの処理方法を形作っています。目標は Amazon のデータレイクポートフォリオを拡張し、開発者が配管よりもドメインロジックに集中できるようにすることであり、エンタープライズ向けにはデータサイエンス、機械学習、メディア処理などで、コストの高いマイグレーションや新しいツールを必要とせずにローカルとオブジェクトストアへのアクセスを統一することで恩恵をもたらします。

**RSoC 2026：Redox OS の新しい CPU スケジューラ** | そっか～ニュース