OS-R1: Rule-based RL Kernel Tuning

• OS-R1 is an agentic Linux kernel tuning framework that models configuration as a finite-horizon Markov Decision Process, enabling efficient exploration of 18,000+ knob settings.
• It employs a two-phase training process that first pre-trains for valid configuration edits and then fine-tunes performance, achieving a +5.6% UnixBench improvement over heuristic methods.
• The framework utilizes grouped action sampling and a composite reward function balancing format, answer validity, and performance to ensure reliable and effective kernel optimizations.

Searching arXiv for the primary OS-R1 paper and closely related OS-agent/kernel-tuning context. arXiv search: "OS-R1 Agentic Operating System Kernel Tuning with Reinforcement Learning" OS-R1 is an agentic Linux kernel tuning framework powered by rule-based reinforcement learning that treats kernel configuration as a finite-horizon Markov Decision Process (MDP), enabling LLMs to explore the configuration space efficiently while preserving accurate configuration modification. The framework combines an environment abstraction over approximately $18{,}000$ kernel knobs, a composite reward function that scores formatting, configuration validity, and performance, and a two-phase training process that separates configuration-level pre-training from end-to-end performance-oriented fine-tuning. In the reported evaluation, OS-R1 significantly outperforms heuristic tuning and several LLM-based baselines on UnixBench, with OS-R1-7B reaching an overall UnixBench score of $662.2$, corresponding to $+5.6\%$ over heuristic tuning; the dataset and code are publicly available (Lin et al., 18 Aug 2025).

1. Problem setting and environment abstraction

Linux kernel tuning is presented as an optimization problem in which existing methods face challenges in efficiency, scalability, and generalization. OS-R1 addresses this by abstracting Linux kernel tuning as a finite-horizon MDP with objective

$$\max_{\pi_t}\; \mathbb{E}_{\tau\sim \pi_t}\left[\sum_{t=1}^{T}\gamma^t R(s_t,a_t,s_{t+1})\right].$$

The state space $S$ encodes three components: the current kernel configuration vector $c\in\{0,1,\ldots,V\}^K$, where $K\approx 18{,}000$ knobs; a workload descriptor $w$, such as an I/O or CPU profile; and system performance metrics $m$, such as throughput and latency. The paper writes the state as $s_t=[c;w;m]\in\mathbb{R}^{d_s}$ and embeds it through $662.2$0 (Lin et al., 18 Aug 2025).

The action space $662.2$1 is defined at the level of configuration groups rather than individual knobs. A single action $662.2$2 selects one configuration group $662.2$3 and sets its value, with actions embedded as one-hot vectors $662.2$4. This grouping is central to the framework’s data-efficiency claims, because it reduces the effective search granularity from the full kernel space to smaller batches of related knobs.

Transition dynamics are operational rather than simulated. Applying an action patches the configuration file, recompiles the kernel, launches the workload, and measures new metrics. Under a fixed hardware and software stack, the transition is described as effectively deterministic. A trajectory is therefore the sequence $662.2$5, where each transition corresponds to an actual system-level intervention and measurement cycle.

2. Policy optimization and rule-based reinforcement learning

To accelerate exploration, OS-R1 employs Group Relative Policy Optimization (GRPO). At each step, the policy samples a group of $662.2$6 candidate actions,

$662.2$7

collects rewards $662.2$8, computes the group mean $662.2$9 and standard deviation $+5.6\%$0, and then defines the normalized advantage

$+5.6\%$1

The policy is then updated by a clipped-PPO-style objective. The use of grouped action sampling standardizes local comparison among candidate edits and is explicitly intended to accelerate exploration (Lin et al., 18 Aug 2025).

The core novelty of the framework is the composite rule-based reward

$+5.6\%$2

The format reward $+5.6\%$3 encourages exact output structure with > …, <tool_call>…</tool_call>, and <answer>…</answer>, and is binary: $+5.6\%$4 if the output format matches exactly and $+5.6\%$5 otherwise. The answer reward $+5.6\%$6 checks whether the proposed configuration edit is valid under the relevant configuration type: Bool requires correct Y/N, Menu requires a subset of candidates, Choice requires exactly one candidate, and Value requires a value within the numeric or enum domain.

The performance reward $+5.6\%$7 is defined as

$+5.6\%$8

where $+5.6\%$9 and $$\max_{\pi_t}\; \mathbb{E}_{\tau\sim \pi_t}\left[\sum_{t=1}^{T}\gamma^t R(s_t,a_t,s_{t+1})\right].$$0 are new and baseline performance scores, $$\max_{\pi_t}\; \mathbb{E}_{\tau\sim \pi_t}\left[\sum_{t=1}^{T}\gamma^t R(s_t,a_t,s_{t+1})\right].$$1 is configuration complexity such as the number of lines changed, and $$\max_{\pi_t}\; \mathbb{E}_{\tau\sim \pi_t}\left[\sum_{t=1}^{T}\gamma^t R(s_t,a_t,s_{t+1})\right].$$2 scales the edit-cost penalty. The paper characterizes this term as capturing end-to-end system gain while penalizing overly complex edits.

3. Two-phase training process

OS-R1 uses a two-phase training procedure designed to accelerate convergence and minimize retraining across diverse tuning scenarios. Phase 1 is a warm-up stage, described as configuration-level pre-training, whose objective is to teach structured reasoning and valid edits. The reward used in this phase is

$$\max_{\pi_t}\; \mathbb{E}_{\tau\sim \pi_t}\left[\sum_{t=1}^{T}\gamma^t R(s_t,a_t,s_{t+1})\right].$$3

This phase does not yet optimize for system performance; it instead bootstraps schema adherence and valid configuration modification.

Phase 2 is an exploration stage, described as end-to-end fine-tuning, in which $$\max_{\pi_t}\; \mathbb{E}_{\tau\sim \pi_t}\left[\sum_{t=1}^{T}\gamma^t R(s_t,a_t,s_{t+1})\right].$$4 is introduced to drive actual performance gains. The policy update objective is written as

$$\max_{\pi_t}\; \mathbb{E}_{\tau\sim \pi_t}\left[\sum_{t=1}^{T}\gamma^t R(s_t,a_t,s_{t+1})\right].$$5

The training loop alternates between random exploration and policy sampling: with probability $$\max_{\pi_t}\; \mathbb{E}_{\tau\sim \pi_t}\left[\sum_{t=1}^{T}\gamma^t R(s_t,a_t,s_{t+1})\right].$$6, the agent takes a random action; otherwise it samples $$\max_{\pi_t}\; \mathbb{E}_{\tau\sim \pi_t}\left[\sum_{t=1}^{T}\gamma^t R(s_t,a_t,s_{t+1})\right].$$7. After executing the action, the framework measures $$\max_{\pi_t}\; \mathbb{E}_{\tau\sim \pi_t}\left[\sum_{t=1}^{T}\gamma^t R(s_t,a_t,s_{t+1})\right].$$8, $$\max_{\pi_t}\; \mathbb{E}_{\tau\sim \pi_t}\left[\sum_{t=1}^{T}\gamma^t R(s_t,a_t,s_{t+1})\right].$$9, and $S$0, combines them as $S$1, stores transitions, normalizes rewards, computes advantages $S$2, updates $S$3 via clipped-PPO, and decays $S$4 (Lin et al., 18 Aug 2025).

The paper attributes data efficiency to three mechanisms: hierarchical grouping of approximately $S$5 knobs into approximately $S$6 manageable samples; enforcing schema validity at prompt time so that trajectories are not wasted on invalid edits; and the two-phase separation, which teaches valid editing before expensive performance runs.

4. Experimental protocol and benchmark results

The reported evaluation uses UnixBench, including seven subtests and an aggregate score. Baselines include heuristic expert tuning, vanilla LLMs—specifically GPT-4o, DeepSeek-R1, and Qwen2.5-Instruct—and LLM-Assisted AutoOS. The evaluation metrics are UnixBench overall score, subtest scores, and configuration validity rate (Lin et al., 18 Aug 2025).

The main UnixBench results are summarized below.

Model	Overall UnixBench
Heuristic	627.2
DeepSeek-R1	650.5
GPT-4o	632.9
AutoOS	638.8
OS-R1-3B	643.8
OS-R1-7B	662.2

OS-R1-7B attains the highest reported overall score, corresponding to $S$7 relative to heuristic tuning. The paper also states that OS-R1-3B rivals much larger LLMs. This suggests that the rule-based RL formulation and grouped action exploration contribute materially beyond raw model scale, although the exact causal decomposition remains constrained by the reported ablations.

Those ablations isolate the contribution of the reward components.

Reward combination	Perf gain (%)	Validity rate
$S$8 only	+16.6	12.2%
$S$9	+27.1	13.3%
$c\in\{0,1,\ldots,V\}^K$0	+17.2	75.4%
Full (all three)	+35.0	78.1%

The full reward yields both the highest performance gain and the highest configuration validity rate. The contrast between $c\in\{0,1,\ldots,V\}^K$1 and $c\in\{0,1,\ldots,V\}^K$2 indicates that answer validity is the dominant factor in preventing invalid configuration edits, whereas performance awareness alone does not ensure syntactically or semantically correct changes.

5. Generalization, convergence, and practical deployment

OS-R1 is evaluated on unseen workloads including Nginx, Redis, and PostgreSQL. In the reported generalization study, the framework yields $c\in\{0,1,\ldots,V\}^K$3–$c\in\{0,1,\ldots,V\}^K$4 improvements over defaults with no retraining, which the paper presents as evidence of strong cross-scenario transfer (Lin et al., 18 Aug 2025).

Training efficiency is reported over $c\in\{0,1,\ldots,V\}^K$5 steps. OS-R1-7B converges in approximately $c\in\{0,1,\ldots,V\}^K$6 steps and OS-R1-3B in approximately $c\in\{0,1,\ldots,V\}^K$7 steps, with both showing steady improvement from the warm-up phase into the exploration phase. The paper’s comprehensive comparison further reports that OS-R1 leads in performance efficiency, adaptation speed, scalability, and configuration accuracy; heuristic tuning leads in interpretability; and LLM-assisted methods lead in resource usage but lag in accuracy.

The deployment-oriented case studies are framed around three concrete applications. For an Nginx HTTP proxy, OS-R1 optimizes TCP buffer and IRQ affinities and reports $c\in\{0,1,\ldots,V\}^K$8 request/sec. For a Redis in-memory store, it tunes THP and slab allocators and reports $c\in\{0,1,\ldots,V\}^K$9 ops/sec. For PostgreSQL, it adjusts dirty page writeback and the scheduler and reports $K\approx 18{,}000$0 TPS. These case studies are consistent with the paper’s claim that the framework is adaptable across various real-world applications.

Integration into systems workflows is described in operational terms. The OS-R1 agent can be invoked via CLI or REST; a workload profile is supplied and the system returns a full .config file. It embeds a “KB tool” for online lookup of kernel dependency rules, can fit into CI/CD pipelines to automatically retune on hardware or software changes, and is described as requiring minimal manual oversight, with approval needed only for the final configuration before rollout.

6. Position within adjacent OS-agent research and nomenclature

OS-R1 belongs to a line of work in which LLM-based or agentic systems act directly on operating-system-level artifacts, but its scope is specifically Linux kernel tuning rather than GUI navigation or general desktop assistance. This distinction matters because later OS-agent evaluation work emphasizes safety, efficiency, and robustness under multimodal perturbations rather than kernel-performance optimization.

A source of potential confusion is nomenclature. In OS-SPEAR, a later toolkit for the safety, performance, efficiency, and robustness analysis of OS agents, the accompanying methodological note formalizes an “OS-R1” robustness score for the R-subset; however, that note explicitly states that the original OS-SPEAR paper does not explicitly name “OS-R1.” In that context, OS-R1 denotes a single-scalar robustness score based on the average ratio between perturbed and clean step-wise success rates under ten cross-modal disturbances, not the kernel-tuning framework described here (Wu et al., 27 Apr 2026).

This naming overlap does not imply methodological identity. OS-R1 in kernel tuning is an RL-based agentic framework over a deterministic system-configuration loop, whereas OS-SPEAR’s robustness formalization is an evaluation metric for OS agents under perturbation. A plausible implication is that future work on kernel-tuning agents could benefit from the kind of multidimensional evaluation standardized in OS-SPEAR, but such an extension is not part of the OS-R1 kernel-tuning paper itself.