## 定義 HPC ジョブスケジューリングは、待ち行列に並ぶジョブを計算ノードへ割り当てる問題であり、バックフィリング(backfilling)はその代表的な戦略の1つである。EASY バックフィリング(Extensible Argonne Scheduling sYstem)は、待ち行列先頭ジョブのためにノード解放時刻を予約しつつ、待機中のジョブがユーザー宣言のウォールタイム見積もりに基づき先頭ジョブの予約を妨げないと判断できれば先取りして実行させる。スケジューラは各ジョブのランタイム見積もりに基づいて予約と全てのバックフィル判断を行うため、見積もりの質がスケジュール品質を直接左右する。(Source: [[@2026__arXiv__Centile - A Telemetry Foundation Model Evaluated by the Decisions It Drives]]) ## 横断的知見 - （2ソース目以降に蓄積する。現時点では単一ソースのため、定義に記載した内容のみ。） - [スケジューリングポリシーの外出し] SLURM(2003年設計)はコントローラ自身にはデフォルトで単純な FIFO のみを実装し、優先度決定・ジョブ順序変更・バックフィリングのような高度なポリシーは Maui Scheduler や DPCS 等の外部スケジューラへプラグイン API 経由で委譲する設計を採る。EASY バックフィリングのようなポリシーはスケジューラコア機能ではなく外部プラグインの実装詳細として扱われる(Source: [[@2003__JSSPP__SLURM - Simple Linux Utility for Resource Management]])。これは [[@2026__arXiv__Centile - A Telemetry Foundation Model Evaluated by the Decisions It Drives]] が想定する EASY バックフィリング自体が、SLURM のような主流スケジューラでは外部プラグインとして実装される対象であることを示す。 - [WMS 配備と制御面負荷] 共有 Fairshare [[Slurm]] 上の広い [[Nextflow]] ファンアウトでは、ユーザー可視ウォールタイムと帰属可能な制御面 RPC 需要が同時に動く。ネイティブ提出・ジョブ配列・[[HyperQueue]]・[[Flux Framework|Flux]] を clean-start 時計とユーザー別 sdiag で比較すると、本番 Phoenix では集約戦略が両目的を改善し、Flux が最低 RPC、HyperQueue 最速中央値は複製間で不安定だった。単一ユーザー Dev では配列と Flux が速く、HyperQueue は最低 RPC だが最遅(Source: [[@2026__arXiv__Balancing Workload Performance and Slurm Stress - Four Nextflow Deployment Strategies]])。 - [Fairshare と RPC の分離] Fairshare は蓄積 TRES、RPC 集約は提出・照会回数の問題であり別機構である。ジョブ配列は要素スケジューラビリティを保ちつつ提出・ポーリングを償却し、タスク形状がバックフィル適合を、配列グルーピングが主に RPC を制御する、という分離がクラスタ依存の効果を予測する(Source: [[@2026__arXiv__Balancing Workload Performance and Slurm Stress - Four Nextflow Deployment Strategies]])。 ## 未解決の問い - ランタイム見積もりの精度とスケジュール品質(bounded slowdown)の関係は単調ではなく、真のランタイムでのスケジューリングが必ずしも最良のスケジュール品質を生まない([[@2026__arXiv__Centile - A Telemetry Foundation Model Evaluated by the Decisions It Drives]] の実験結果)。「正確だがわずかに保守的な見積もり」が最適となる条件を、EASY 以外のバックフィリング方針(保守的バックフィリング等)でも一般化できるか。 - Centile は「event-timing 入力を使わない最小構成」の推定器が最良の再生結果を出しており、なぜ inter-arrival gap や時刻特徴のような時刻認識入力が改善に寄与しないのかは論文内で分析されていない。この現象は F-DATA 固有か、他の HPC トレースでも再現するか。 - SLURM のようにスケジューリングポリシーをコアから分離し外部プラグイン(Maui/DPCS 等)に委譲する設計は、ランタイム見積もり精度に対するスケジュール品質の感度(Centile が観察した非単調性)にどう影響するか。ポリシー実装がスケジューラ本体の外にあることで、見積もり誤差の影響を測定・チューニングする経路は変わるか。 - 大学 Fairshare [[Slurm]] 以外(商業キュー、予約パーティション、非 sdiag 環境)でも、clean-start + ユーザー別 RPC 帰属による WMS 配備比較は成立するか。成立条件は何か(Source: [[@2026__arXiv__Balancing Workload Performance and Slurm Stress - Four Nextflow Deployment Strategies]])。 - 終端タスク基数や DAG 形状をスイープしたとき、総 RPC がタスク数に比例し集約の価値が増すという仮説は、配列 / HQ / Flux で同様に成り立つか(Source: [[@2026__arXiv__Balancing Workload Performance and Slurm Stress - Four Nextflow Deployment Strategies]])。 ## 関連 - [[@2026__arXiv__Centile - A Telemetry Foundation Model Evaluated by the Decisions It Drives]] — EASY バックフィリングのウォールタイム推定を生成的テレメトリ基盤モデルの分位点で置き換え、bounded slowdown を最大約77%改善 - [[決定志向予測評価]] — バックフィリングのような下流意思決定でモデルを評価する枠組み - ソース: [[@2003__JSSPP__SLURM - Simple Linux Utility for Resource Management]] / [[@2026__arXiv__Balancing Workload Performance and Slurm Stress - Four Nextflow Deployment Strategies]] - エンティティ: [[SLURM]] / [[Nextflow]] / [[HyperQueue]] / [[Flux Framework]] - 概念: [[パイロットジョブ]] ## 出典 - [[@2026__arXiv__Centile - A Telemetry Foundation Model Evaluated by the Decisions It Drives]] - [[@2026__arXiv__Balancing Workload Performance and Slurm Stress - Four Nextflow Deployment Strategies]](Nextflow–Slurm 4 配備のウォールタイム–RPC フロンティアと Fairshare/RPC 分離)