SemaTune: Semantic OS Tuning Framework
- SemaTune is a host-side framework that uses LLMs as semantic reasoners to safely tune Linux OS parameters in real time.
- It employs a dual-loop control mechanism with fast adjustments and periodic strategy revisions to balance latency and depth of reasoning.
- Evaluations on 13 workloads show up to 72.5% improvement over defaults and 153.3% gain over non-LLM baselines when tuning up to 41 parameters.
SemaTune is a host-side framework for online operating-system tuning that uses LLMs as semantic reasoners inside a carefully constrained control loop. It is designed for steady-state OS tuning of long-running services on live Linux hosts: a fast loop proposes low-latency updates, a slower loop periodically revises the search strategy, and every proposed change passes through typed validation before reaching kernel or sysctl interfaces. In evaluation on 13 live workloads from five benchmark suites while tuning up to 41 Linux parameters, SemaTune improves stable-phase performance by 72.5% over default settings and by 153.3% relative to the strongest non-LLM baseline; a 30-window session costs about \$0.20 in model calls (Liargkovas et al., 14 May 2026).
1. Problem setting and design thesis
SemaTune addresses online OS tuning, in which a controller repeatedly observes metrics, chooses new knob values, applies them, observes how the system responds, and repeats. The knobs are runtime parameters that alter policies for CPU scheduling, power management and DVFS, CPU idle states, networking and I/O, and memory and writeback. The controller operates out-of-band on timescales of seconds to minutes rather than on the fast path of each request.
The framework is motivated by a specific failure mode of conventional tuners. Existing controllers are described as poorly matched to live hosts because they treat scheduler, power, memory, and I/O controls as black-box variables and optimize a scalar reward. This view ignores cross-knob policy structure, breaks down when application metrics are unavailable, and can send a running service into degraded regions that persist after the bad setting is removed. The paper gives concrete examples of semantic unsoundness: min_perf_pct > max_perf_pct, and combinations such as extreme busy-polling, shallow idle states, and long scheduler slices for a latency-sensitive service. In Memcached experiments, MLOS repeatedly enters such regions and causes more than 47× p99 spikes. In PostgreSQL–Wikipedia, tuning with IPC or LLC misses as reward yields worse p99 than tuning with application p99, with degradation of up to 2×. In PostgreSQL–TPC-C, expanding from 1 to 32 knobs degrades p99 by about 50% under MLOS. These cases support the paper’s central claim that the dominant difficulty is semantic rather than merely numerical: a controller must reason about what knobs mean, what telemetry indicates, and how policies interact (Liargkovas et al., 14 May 2026).
2. Framework architecture and execution model
SemaTune is organized as a host-side pipeline that begins with a typed tuning request and ends with guarded writes to kernel interfaces. A session specification identifies the target workload, the goal, the knob set, and the tuning horizon. An API–Telemetry layer attaches to the workload and measurement infrastructure, collecting application metrics when available—such as p99 latency and throughput—and system metrics including perf stat counters, RAPL power, CPU utilization, C-state residency, run queues, and I/O metrics.
A Context Manager combines knob schema and metadata, the current knob configuration, the latest telemetry, recent action–response history within the session, and cross-run memory retrieved from a vector store. The output is a structured decision context and prompt. The Tuner contains a dual-loop LLM controller. A Parameter Validator enforces typed schema and policy constraints, filters invalid or disallowed proposals, and applies accepted updates atomically. Actuation occurs through sysctl, sysfs, debugfs, cpufreq, and intel_pstate, under a host-side lock. On failure, the previous safe configuration remains in effect. Each decision’s action, resulting configuration, telemetry, and justification are logged, and session-end summaries can be stored for reuse in later runs.
The decision context is explicitly split into stable and dynamic parts. The stable portion includes the role, the goal, the active knob list, per-parameter metadata such as types, ranges, domains, scope, and dependency hints, a textual strategy, and a cross-run prior. The per-iteration portion includes the current configuration, latest metrics, and a trace of recent action–response history. This separation keeps repeated requests compact while preserving enough temporal structure for trend interpretation (Liargkovas et al., 14 May 2026).
3. Dual-loop control and bounded semantic reasoning
The core control mechanism is a dual-loop design that balances latency, model cost, and reasoning depth. The fast loop, called Instant, runs every tuning window, typically every 1–5 seconds. It uses a lighter model—Gemini 2.5 Flash-Lite in the reported experiments—and is responsible for local exploration, small low-risk adjustments, and quick corrective moves when performance worsens. The slow loop, called Reasoning, runs less frequently, typically every 30–60 seconds, and uses a more capable model—Gemini 2.5 Flash—to reinterpret the multi-window trajectory, update the search policy, prioritize subsystems, and summarize recent history into a new persistent strategy entry.
History management is explicitly compressed. Instant calls see all persisted Reasoning entries and all Instant entries since the last Reasoning call. A Reasoning call consumes the accumulated Instant entries, sees the existing Reasoning entries and the most recent Instant history, and emits a new Reasoning entry. Previous Instant entries are then removed from future contexts. This keeps context growth bounded by the number of Reasoning summaries rather than by the full sequence of per-window actions.
The LLMs are used as semantic controllers rather than as open-ended agents. They interpret knob schemas, assess whether candidate configurations are semantically coherent as policies, infer progress from indirect telemetry when application metrics are absent, guide exploration in high-dimensional knob spaces, and leverage prior runs. Prompts are structured, not free-form. Outputs must conform to a response schema derived from the active tunable set and consist of typed knob updates, a short justification, and optional convergence flags. The authority boundary is strict: no raw shell commands, no arbitrary OS APIs, and no direct kernel modification without validation. The dual-loop architecture also bounds cost. A 30-window session costs about \$0.20 with dual-loop SemaTune, compared with about \$0.42 for a single-Reasoning baseline and about \$0.12 for a single-Instant baseline (Liargkovas et al., 14 May 2026).
4. Optimization logic, indirect objectives, and semantic safety
SemaTune does not implement a formal Bayesian optimizer or RL policy. The paper instead characterizes the method as LLM-guided heuristic search grounded in observed numeric feedback and constrained by semantics. The tuning objective can be written as
where is the vector of allowed OS knob settings and is the performance objective, typically negative p99 latency for latency-sensitive workloads or throughput for throughput-sensitive workloads. The framework can also operate under constraints such as
Search behavior is staged. Early windows emphasize safe exploration and information gathering, often warm-started by cross-run memory. Middle windows narrow ranges for influential knobs and may freeze knobs that appear irrelevant. Late windows exploit the best-known region and make small changes until performance stabilizes. In the experimental protocol, steady state is operationalized as 30 tuning windows followed by 20 stable windows during which SemaTune applies no further changes and holds the last accepted configuration fixed.
When application metrics are unavailable, SemaTune does not replace them with a fixed scalar proxy such as IPC or LLC misses. Instead, it uses what the paper describes as a semantic surrogate: whether the joint host telemetry is trending toward a healthy operating point. The model reasons over CPU utilization, run queues, IPC, LLC misses, power, C-state residency, and I/O signals jointly. This is significant because single low-level proxies were shown to be brittle in the PostgreSQL–Wikipedia case.
Semantic safety is central to the method. The framework rejects logically inconsistent proposals such as min_perf_pct > max_perf_pct, and it is intended to avoid numerically valid but policy-unsound combinations. The Memcached case illustrates this role directly: MLOS proposes contradictory DVFS ranges and explores extreme busy_poll, shallow C-states, and long scheduler windows, producing p99 spikes to 64–68 ms and later 54 ms from a baseline around 1.4 ms, with throughput falling from about 500k req/s to about 425k req/s. The Xapian case illustrates a different failure mode, a queue-dominated metastable regime with extremely high p99 that classical tuners do not recover from within the tuning session. SemaTune is reported to avoid these catastrophic regions by interpreting telemetry patterns and refusing semantically dubious moves (Liargkovas et al., 14 May 2026).
5. Experimental evaluation and quantitative findings
The evaluation is conducted on CloudLab hosts with two Intel Xeon Silver 4114 CPUs, 192 GiB DRAM, Ubuntu 22.04.2 LTS, and Linux 5.15.0-160-generic. The workload suite comprises 13 benchmarks from five suites: Memcached with Mutilate; BenchBase on PostgreSQL 14 with TPC-C, Wikipedia, YCSB, Twitter, and SIbench; Tailbench with Masstree, Silo, Xapian, and Sphinx; Sysbench CPU and OLTP Read-Write; and DCPerf Sparkbench. The default tuning set contains eight coupled Linux knobs: four CFS parameters (min_granularity_ns, latency_ns, wakeup_granularity_ns, migration_cost_ns), three DVFS/idle parameters (min_perf_pct, max_perf_pct, cstate_max), and napi_busy_poll. Larger experiments expand the control surface to 41 knobs. Each run uses 30 tuning windows of 5 seconds each, followed by 20 stable windows, with five independent runs per workload.
Across the full 13-workload suite in stable phase, SemaTune achieves +72.5% over Default and +153.3% over the strongest non-LLM baseline. MLOS is approximately –31.9% versus Default on the full set; Bayesian is –37.46%; DQN is –44.49%; Q-Learning is –58.49%; and SemaTune-Trim is –26.14%. During tuning windows 1–30, SemaTune is +59.36% over Default, whereas MLOS is –33.79%, SemaTune-Trim is –30.62%, Bayesian is –45.77%, DQN is –40.41%, and Q-Learning is –51.66%. On the non-catastrophic subset, SemaTune yields +87.2% stable gain at about \$0.20, Single-Reasoning yields +89.7% at about \$0.42, Single-Instant yields +25.4% at about \$0.12, SemaTune-Trim yields +63.9% at about \$0.15, and MLOS yields +50.5% at \$0.
The indirect-tuning results are a major part of the framework’s claim. With only host metrics, SemaTune still achieves +21.7% during tuning and +31.9% in stable phase on the full set, and +64.0% stable on the non-catastrophic subset. The paper states that SemaTune with only system metrics still outperforms MLOS even when MLOS has direct application metrics, and on non-catastrophic workloads the margin is about 13.5 percentage points.
Robustness is evaluated through bad-window rates and variability. Excluding catastrophic workloads, SemaTune has P50 bad-window rate 16.9%, P10 bad-window rate 12.0%, and variability 11.1%, compared with MLOS at 28.8%, 26.3%, and 25.1%, and SemaTune-Trim at about 29.7%, 29.6%, and 24.7%. Dimensional scalability is tested at 1, 8, 16, 32, and 41 knobs. On TPC-C, Sysbench OLTP-RW, and Silo, SemaTune stable-phase improvement is +216.7% at 8 knobs, +213.4% at 16, +105.0% at 32, and +155.9% at 41. MLOS performs well at 4–8 knobs but degrades at higher dimensions, reaching +13.0% stable and –11.1% during tuning at 41 knobs. Median decision latency for MLOS rises from 0.49 s at 1 knob to 5.73 s at 41 knobs. SemaTune’s Instant latency remains about 1.0–2.6 s across 1–41 knobs, while Reasoning latency is 8–16 s but infrequent and off the critical path.
Cross-run memory improves transfer when aggregated rather than retrieved as a single run. On unseen workloads with application metrics, no-memory stable performance is +144.7%, Top-1 retrieved memory is worse, and Top-3 reaches +202.9% stable and +155.6% during tuning. With system metrics, no-memory stable performance is +143.1%, and Top-3 reaches +164.4% stable and +143.7% during tuning. Backend sensitivity experiments show that Gemini 2.5 Flash gives the best reported performance at +153.7% during tuning and +216.7% stable for about \$0.20; Gemini 3 Flash is somewhat worse and more expensive; Kimi K2 is markedly cheaper at about \$0.048 with lower average performance and higher variance (Liargkovas et al., 14 May 2026).
6. Limitations, relation to prior work, and terminological scope
SemaTune is explicitly designed for steady-state tuning of long-lived services. The paper identifies several limitations: it is less suited to short-lived batch jobs, highly bursty workloads with sub-second dynamics, and multi-tenant settings with multiple primary applications per host; it depends on accurate knob schemas, documentation snippets, and dependency encoding; it is evaluated on Linux 5.15 on x86 rather than across multiple kernels and architectures; and its safety ultimately depends on correct validator implementation and reliable kernel interfaces. The paper also notes the threat of model behavior drift, since the system assumes models with sufficient systems knowledge and reasoning capability.
In the literature review, SemaTune is distinguished from black-box autotuners such as CherryPick, OtterTune, SmartConf, MLOS, OPPerTune, SelfTune, and TUNA, which represent knobs as numeric or categorical variables and optimize a scalar reward. It is also distinguished from LLM-assisted tuners such as DB-BERT, GPTuner, λ-Tune, Booster, and AutoOS, which use LLMs offline to read manuals, filter knobs, suggest initial configurations, or bootstrap classical tuning. SemaTune’s stated conceptual contribution is bringing LLM-based semantics into live OS tuning through a dual-loop runtime architecture, typed validation, semantic cross-knob reasoning at runtime, and cross-run memory. It is further separated from broader agentic systems such as AIOS, Herding LLaMaS, Kgent, sched-agent/SchedCP, and learned OS-policy systems such as LinnOS, LAKE, and Heimdall, because it does not replace a subsystem with a learned policy and does not grant shell-like authority; it remains a host-side controller over existing OS knobs (Liargkovas et al., 14 May 2026).
The name also requires disambiguation. In the provided arXiv sources, only one paper explicitly defines SemaTune as a system: the OS-tuning framework above. A separate paper, “Sema: Semantic Transport for Real-Time Multimodal Agents”, defines Sema, not SemaTune, and states that the term “SemaTune” does not appear anywhere in that paper (Meng et al., 22 Apr 2026). Another paper on semantic timbre control in wavetable synthesis was described as mapping naturally onto the idea of semantic control, but the paper itself is titled “Wavetable Synthesis Using CVAE for Timbre Control Based on Semantic Label” rather than SemaTune (Yutani et al., 2024). This suggests that, within the current arXiv record supplied here, SemaTune has a precise and formal meaning in systems research: semantic-aware online tuning of live operating systems under bounded language-model guidance.
