Scheduler Policy Repository

• Scheduler Policy Repository is a structured, extensible system that stores and organizes scheduling algorithms along with rich metadata for adaptive scheduling.
• It integrates data-driven workload recognition and mapping mechanisms to support dynamic policy selection and rapid switching in real-time system deployments.
• It promotes research and practical deployment through version-controlled updates, continuous benchmarking, and reproducible evaluation methodologies.

A Scheduler Policy Repository is a structured, extensible system for storing, organizing, and operationalizing a collection of scheduling algorithms ("policies") and associated metadata. Its function is to support adaptive scheduling agents, policy research, and practical system deployments by enabling efficient policy discovery, rapid switching, dynamic adaptation, and reproducible benchmarking across heterogeneous workloads and hardware. Such repositories are foundational components for next-generation scheduling systems, particularly in operating systems, datacenter orchestration, memory controllers, and AI-driven environments. The following sections synthesize rigorous technical detail on the design, operation, and evaluation of modern Scheduler Policy Repositories, focusing on concrete data structures, ML-driven adaptation logic, update and extension workflows, and evaluation methodologies, as exemplified by leading research such as the ASA agent design (Wang et al., 7 Nov 2025).

1. Data Structures and Policy Representation

Policies in a Scheduler Policy Repository are persistently catalogued with extensible, metadata-rich records adapted for both in-memory and on-disk management.

In-memory structure:

struct SchedulerPolicy { uint32_t policy_id; // Unique numeric ID char name[32]; // Human-readable identifier (e.g., "scx_lavd") char ebpf_obj_path[128];// Path to binary (eBPF object for OS policies) uint32_t cooldown_ms; // Minimum ms between switches to mitigate thrashing uint32_t preload_priority; // Load ordering };

On-disk layout:

/etc/asa/policies/ manifest.json # Global index scx_lavd.o # Policy binary (eBPF, if for OS) scx_lavd.meta.json # Per-policy metadata (see schema below) ...

Metadata schema (JSON example): $$h = \operatorname{ReLU}(W_1 x + b_1) \in \mathbb{R}^k \ z = W_2 h + b_2 \in \mathbb{R}^C \ p = \operatorname{softmax}(z)$$0 This structure allows filtering by workload class and hardware compatibility, supports cost-aware switching (cooldowns), and enables reproducible mapping between scenario and policy (Wang et al., 7 Nov 2025).

2. Workload Recognition and Policy Mapping

Scheduler Policy Repositories integrate data-driven mechanisms for dynamic workload identification and scheduler selection, central to adaptive agent operation.

2.1 Workload Recognition

A hardware-agnostic ML model (e.g., MLP or XGBoost ensemble) is trained offline to classify real-time workload patterns:

• Input vector $x\in\mathbb{R}^D$: System feature sweep (CPU statistics, memory, disk, process, network metrics)
• Model: Two-layer MLP

$$h = \operatorname{ReLU}(W_1 x + b_1) \in \mathbb{R}^k \ z = W_2 h + b_2 \in \mathbb{R}^C \ p = \operatorname{softmax}(z)$$

• Output: Probability vector $p$ over workload classes

Time-weighted probability voting aggregates predictions over sliding windows with exponential decay:

$w(\tau) = \alpha^{W-\tau},\ \alpha\in(0,1)$

$$P_i(t) = \frac{\sum_{\tau=1}^t w(\tau) \cdot I_i(\tau)}{\sum_{j=1}^k \sum_{\tau=1}^t w(\tau) \cdot I_j(\tau)}$$

Low-confidence timesteps ($p^{(\tau)}_c < \theta$) are filtered to stabilize class output (Wang et al., 7 Nov 2025).

2.2 Policy Mapping Table

A mapping from identified workload class to optimal policy is maintained: $$h = \operatorname{ReLU}(W_1 x + b_1) \in \mathbb{R}^k \ z = W_2 h + b_2 \in \mathbb{R}^C \ p = \operatorname{softmax}(z)$$1 This is materialized both in JSON for persistence and as an eBPF array (for OS context) supporting kernel-level lookups with $O(1)$ access.

Upon hardware or scenario update, only the mapping table must be revised—no retraining of the classifier core is required (Wang et al., 7 Nov 2025).

3. Policy Switching and Runtime Integration

Policies can be switched dynamically by integrating with kernel or application-level hooks, minimizing runtime overhead.

OS example (Linux sched_ext):

1. bpf_prog_detach(current_prog)
2. bpf_prog_attach(policy[P].ebpf_obj)
3. Enforce a cooldown (e.g., $500$ ms) to avoid policy oscillation.

The policy switch latency is sub-microsecond per context switch when implemented with sched_ext, making rapid, workload-dependent adaptation practical for production systems (Wang et al., 7 Nov 2025).

General agent workflow:

1. Collect system features.
2. Infer workload class.
3. Lookup optimal policy via mapping table.
4. If new class, update mapping table after evaluation.

4. Repository Extension, Maintenance, and Best Practices

A Scheduler Policy Repository must be robust against evolution in workloads, hardware, and research advances.

4.1 Adding Expert Policies

Steps:

1. Implement and compile the new policy (e.g., as a sched_ext eBPF program).
2. Create a metadata file matching schema.
3. Update /etc/asa/policies/manifest.json and copy files to repository.
4. Execute Stage 1/2/3 of evaluation workflow (see below) for performance+compatibility.
5. Revise the mapping table as needed and hot-reload if supported.

4.2 Continuous Integration and Versioning

Best practices include:

• Per-policy documentation (“readme.md”) with use-case and overheads.
• Controlled tag vocabularies for workload and hardware descriptors.
• Automated benchmarking on each policy or mapping update (prototype runs, calibration, mapping re-generation).
• Reproducible benchmarking scripts; archiving of raw metrics and policy versions.
• Version control (git tags, atomic mapping table swaps for rollback, semantic commit enforcement) (Wang et al., 7 Nov 2025).

Testing encompasses containerized deployment, synthetic workload injection, and lookup validation.

5. Benchmarking and Evaluation Methods

Rigorous evaluation is essential for policy ranking and mapping table construction.

5.1 Benchmark Suite

Typical test matrices span:

• User-centric workload blends (interactive, batch, background, heavy-tailed).
• Heterogeneous hardware (core types, memory layouts, device classes).
• User-experience–driven metrics (latency, throughput, fairness).

5.2 Key Evaluation Metrics

Empirically measured:

• Win rate over OS baseline (e.g., 86.4% over Linux EEVDF)
• Top-1 and top-3 oracle selection frequency (ASA achieves 45.4% and 78.9%, respectively)
• Geometric mean improvement on normalized user-experience metrics (8.83% mean with 95% CI [7.08%, 10.59%])
• Benchmark-wide heatmaps for policy performance across scenario×hardware

Metric	EEVDF	ASA Agent	Static Oracle
Overall Win Rate vs EEVDF	---	86.4%	---
Mean User-Experience Score (normalized)	0.62	0.676	0.701
Top-1 Ranking Frequency	---	45.4%	100%
Top-3 Ranking Frequency	---	78.9%	100%

Benchmarks may include trace-driven systems, synthetic mixtures, and active learning feedback loops (Wang et al., 7 Nov 2025).

6. Practical Impact and Adaptation

Scheduler Policy Repositories enable deployment of adaptive, modular scheduling agents decoupled from hardware and fast to re-target. Rapid extension and minimal retraining allow continual policy evolution as new expert schedulers, kernel modules, or ML-driven algorithms emerge. By structuring metadata and evaluation within a unified system, they bridge research and practical system operations, promoting reproducibility, faster incorporation of advancements, and fine-grained workload tailoring in heterogeneous computing environments.

A plausible implication is that such repositories will underpin modern OS scheduling, cloud orchestration, and cloud-edge-environment adaptation, supporting both static expert policies and dynamically learned, environment-specific schedulers (Wang et al., 7 Nov 2025).