The Linux kernel contains constants that are not configuration in the usual sense. They set loop bounds, batch sizes, retry counts, queue-merging windows, and timing thresholds. A compiler may propagate one value through branches, arithmetic, tables, and generated instructions. That specialization is efficient, but it freezes a workload assumption into every deployed host.
Xkernel calls these values performance constants, or perf-consts. They are not correctness parameters: several values preserve semantics while shifting latency, throughput, CPU use, and resource pressure. A static default must compromise across workloads. A cloud operator, however, can observe which workload is running and may want a different point on the tradeoff curve without rebuilding or rebooting the fleet.
Making the constant a writable variable is insufficient. The compiler may have removed the load, folded comparisons, unrolled loops, or initialized state that persists after the value changes. A general live patch can replace binary regions, but generating and safely applying a new patch for every policy decision is too slow and operationally heavy. Xkernel tries to retain compiled code while exposing only the affected scopes as runtime choices.
A constant leaves state behind
Consider an I/O merge limit. Its literal value can appear in a branch, but it can also determine the size or meaning of nearby state. Changing only the branch operand while old counters remain live may create a transition that no clean kernel execution could have reached. Safe tunability therefore requires an account of both instructions and state.
Xkernel analyzes uses of a selected perf-const offline. It identifies critical spans where the value changes behavior and derives symbolic state expressions that describe the state needed under a candidate value. The result is reusable across future values, so the expensive analysis is amortized before deployment.
The paper favors sound, scoped support over the claim that every constant can be transformed. Pointer-heavy flows, unsupported Kprobe sites, assembly, and effects beyond the analysis model can reject a candidate. This is an important engineering boundary: a knob appears only after the tool can explain its transition.
Scoped indirect execution preserves specialization
Scoped Indirect Execution (SIE) is the runtime mechanism. A Kprobe or kernel function hook intercepts an affected point, evaluates the current policy value, reconstructs the corresponding state, and directs execution through a prepared scope. Unrelated kernel code stays unchanged and optimized.
This differs from adding a global indirect branch to every use. The analysis chooses locations and state transfer together. A value can be global, per-core, per-task, or selected by workload context, allowing finer policy granularity than one sysctl for the entire host.
The implementation uses approximately 1.7 thousand lines of kernel C and a larger Python analysis stack. It relies on stable Linux tracing machinery but minimizes expensive breakpoint and single-step paths where possible. A control service can change values at millisecond scale, which is fast enough for workload phases but not intended for every packet or instruction.
Runtime safety also includes synchronization. Concurrent threads must not observe an invalid mixture of old state, new policy, and partially applied code. Xkernel defines the critical scope and uses the kernel’s existing synchronization context where possible. An operator still needs rate limits and rollback because a semantically valid value can be a performance disaster.
Case studies expose real tradeoff surfaces
The evaluation spans CPU interrupt handling, storage, memory migration, and networking. One constant controls how many softirq operations the kernel processes before yielding. A larger value amortizes interrupt work and raises throughput, while a latency-sensitive task can wait longer. Xkernel makes that curve measurable and selectable for a colocated workload.
A storage case changes a batching or merging threshold. The default can add unnecessary disk work for one device and request shape, while a smaller value reduces latency. Another case adjusts the number of migrated pages before a TLB shootdown, trading fewer synchronization events against longer exposure to cold placement.
The networking examples change TCP behavior for different round-trip regimes. The paper reports an 81% reduction at the P99.99 flow-completion tail in one condition. RocksDB improves throughput by 1.2×, and isolated microbenchmarks reach up to 50×. Those numbers do not describe a universal kernel speedup; they show how far a fixed default can be from the right value for a deliberately selected workload.
The correct comparison is at equal service objectives. Maximizing throughput while quietly increasing a colocated task’s P99 latency is not a win. Xkernel exposes the control point, while a higher-level policy must specify whose latency, CPU use, fairness, or power limit governs the choice.
Mechanism overhead is concentrated at triggers
An SIE invocation costs a few hundred cycles, including the underlying probe and state work. For extremely small operations, that fixed cost can be visible. The evaluation reports about 15% slowdown when useful work per operation is very short; it falls to 5% and 2% as work grows, and below 1% at roughly 20 microseconds per operation.
Multiple probes accumulate cost. In a Redis test, 32 active SIE probes reduce throughput by at most 4%; even 128 remain bounded but are not free. The practical deployment pattern is therefore selective activation, not converting every literal into a live knob.
Offline analysis cost grows roughly linearly with the number of constants and is paid once for a kernel build. This shifts work from every machine and every update into a validated artifact pipeline. Build identity becomes part of the control plane: an analysis result cannot silently move to a different binary.
Tunability does not select the policy
Xkernel provides mechanism and measurement hooks, not a complete automatic tuner. A production controller must decide when workload evidence is strong enough to change a value, how long to observe the result, and what rollback threshold applies. Rapid actuation can otherwise create oscillation between two locally attractive settings.
Policies should include hysteresis, minimum residence time, and a safe default. Changes should carry the kernel build, perf-const identifier, old and new values, scope, trigger count, SLO measurements, and rollback outcome. A canary group is appropriate because the analysis guarantees a supported transition, not the absence of unmodeled workload interactions.
Security boundaries matter as well. A writable batching or retry threshold can be used for denial of service even if memory safety is preserved. The interface needs privilege separation and an allowlist of values validated during analysis. Tenant input should influence policy through constrained metrics, not directly select kernel constants.
Treat kernel specialization as a deployable contract
Traditional kernel configuration places a line between compile-time specialization and runtime flexibility. Xkernel moves that line for selected constants by packaging dependency analysis, state transition, instrumentation, and control metadata together. It preserves fast code outside the chosen spans while offering a much faster alternative to rebuilding or live-patching a new kernel.
The strongest use case is a stable fleet with recurring workload classes whose optimal point changes by phase, tenant, or hardware. A single-purpose appliance with one known workload may prefer an offline-tuned constant. A rapidly changing upstream kernel may find the analysis and validation pipeline expensive.
The systems implication is broader than Linux knobs. Compilers routinely erase configuration decisions to gain speed. If operators later need those decisions, the right abstraction is not necessarily a variable. It can be a verified transition over code and state, bounded to the places where the decision matters.
Validation should follow the control artifact
Each transformed perf-const should ship with machine-readable evidence: supported kernel build hashes, legal values, affected scopes, synchronization assumptions, expected trigger frequency, and a workload-independent safety test. Continuous integration can boot every candidate value under stress, while performance qualification checks only the smaller set intended for a service. This separates semantic permission from policy preference.
Fleet rollout should measure both sides of every advertised tradeoff. A storage threshold can improve median latency but harm recovery bandwidth; a network threshold can reduce long-flow tails while increasing short-flow CPU. The controller should stop changing a value when telemetry is missing, the binary identity differs, or the observed trigger rate exceeds the analyzed envelope. The best feature of fast actuation is safe reversibility, not constant motion.
Source and copyright notice
This article is an editorial analysis by Silicon & Systems. It restates the design, case studies, measurements, and limitations in our own words. No source sentence, table, or figure is reproduced; the figure was created for this article. The paper is available from the USENIX OSDI 2026 presentation page. Copyright remains with the authors, 2026.