Pith. sign in

REVIEW 4 major objections 6 minor 2 cited by

Xkernel: Principled Performance Tunability of Operating System Kernels

T0 review · 4 major / 6 minor · reviewed 2026-08-03 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read KernelX claims that any performance-critical constant in a deployed Linux kernel can be safely turned into a runtime-tunable knob, without recompilation or reboot, by synthesizing state-update snippets at the exact binary locations where th

desk verdict KernelX's SIE is a genuinely new mechanism for runtime tuning of kernel constants, but the 'any perf-const' claim outruns the evidence and the paper ships no artifacts to verify its numbers. read the letter →

arxiv 2512.12530 v2 pith:DU7HKVEL submitted 2025-12-14 cs.OS

Zhongjie Chen , Wentao Zhang , Yulong Tang , Ran Shu , Fengyuan Ren , Tianyin Xu , Jing Liu This is my paper
classification cs.OS
keywords performancetuningoperatingsystemsLinuxkernelperf-constsScopedIndirectExecutioneBPFlivepatchingruntimetunability
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper tries to establish that the fixed numeric constants that shape Linux performance—thresholds, intervals, batch sizes, scaling factors—form a large, untapped tuning space, and that they can be made dynamically adjustable on a running kernel. To do this it introduces Scoped Indirect Execution (SIE), which locates the precise instruction where a constant first affects registers or memory, captures that effect as a small symbolic expression, and redirects execution to synthesized code that updates the state as though the new value had been compiled in. The claimed result is millisecond-scale, side-effect-safe value updates for any perf-const, with no kernel recompilation or reboot, plus a programmable eBPF policy plane. If correct, this would convert every hardcoded magic number into a live knob and let OS behavior adapt online to workloads, hardware, and service-level objectives.

What carries the argument

The central object is the symbolic state expression R/M ← f(R/M, IV), recovered for each perf-const. It carries the argument by reducing constant replacement to a state-update problem: instead of patching instructions, KernelX synthesizes snippets that overwrite the affected architectural state. The critical span is the binary interval covered by that expression; the safety span is the thin-slice closure of everything transitively dependent on the constant. The expression also makes update correctness checkable via the invariant Exec(σin, CS_v ∘ I) ≡ Exec(σin, CS_v′).

What would settle it

Take a perf-const that the compiler folds into a non-linear or multi-site form—e.g., used as V×V, as both a multiplier and a shift amount, or in an expression combining two constants—and run the x-gen/x-load workflow on a deployed kernel. If the tool cannot fit IV = a·V + b, or if after a transition some path still exhibits the old value, the 'any perf-const' guarantee is refuted. A second test: deliberately choose a constant whose safety span misses a side effect visible to another thread and check for inconsistent state after global consistency transitions.

Watch

Extended reading notes

Core claim

The central discovery is that a perf-const's compiled influence is structurally scoped: it enters architectural state at a well-defined binary boundary and propagates through a small instruction sequence. KernelX recovers the symbolic state expression R/M ← f(R/M, IV) for that boundary using binary differencing and symbolic execution, where IV is the compiler-transformed value, then maps IV back to the source value V by linear interpolation. It synthesizes {location, update} indirections that overwrite registers or memory so that exiting the critical span is observationally equivalent to having executed the span with the new value. A separate safety span, built by forward thin slicing, conta

Load-bearing premise

The whole approach rests on every tunable constant's compiled effect being recoverable as a small, univariate, linear symbolic expression that two rebuilt binaries can expose; if an optimizer ever produces a non-linear or multivariate form, or an inlined call site that symbolic execution misses, SIE could update the wrong state or leave stale remnants.

Editorial extensions

If this is right

  • Tuning no longer requires sysctl-style source conversions: any perf-const named by file, line, and token becomes a knob in milliseconds; the evaluation reports 99.3% support across 140 constants.
  • SIE overhead is small enough for hot paths: a jump-optimized probe costs about 243 cycles, and slowdown drops below 1% once per-operation work reaches 20 µs.
  • Transitions can be made safe under concurrency: per-thread version atomicity is guaranteed by the critical span, and global consistency by reference-counted self-convergent transition, with transition times in the low tens of milliseconds.
  • Policies can inspect kernel and hardware state and apply context-dependent values (per-shrinker, per-flow, per-thread) from eBPF, enabling adaptive tuning such as the case-study NGINX policy that cut P99.99 latency by 81%.
  • Case studies show the untapped headroom: 54x write throughput on HDD by raising BLK_MAX_REQUEST_COUNT, and 1.2x RocksDB throughput on NVMe by lowering it.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The same SIE idea could extend beyond Linux to other compiled systems with hardcoded tunables—hypervisors, firmware, or user-space runtimes—provided they expose a stable tracing or probe mechanism; the paper only evaluates Linux.
  • If the symbolic-expression premise holds broadly, kernel developers could stop converting constants into sysctls (a process the paper shows takes years and often introduces races) and ship scope tables as kernel artifacts instead; the paper does not propose this workflow.
  • A testable extension is an automatic search agent that sweeps perf-const values through KernelX's API to map cost-benefit curves online; the paper demonstrates such curves but treats them as user-driven experiments, not as an autonomous tuner.
  • The one unsupported constant in the evaluation fails due to a symbol-resolution ambiguity in Kprobe, not SIE; fixing that attachment layer would be a natural robustness improvement the paper leaves open.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper presents KernelX, a Linux framework for in-situ retuning of hard-coded performance constants ('perf-consts') without recompilation or reboot. The core mechanism, Scoped Indirect Execution (SIE), statically recovers a symbolic expression for the architectural-state effect of each perf-const, identifies a critical span and a safety span, and synthesizes kprobe/eBPF update code that rewrites registers/memory so that execution after the span matches execution with a new value. The authors evaluate SIE on 140 perf-consts, reporting 139 supported, with 367 critical spans and 300 safety spans. Case studies cover block I/O plugging, softirq handling, shrinker batching, NUMA page migration, and TCP CUBIC HyStart, showing substantial throughput/latency improvements, policy-update times below 542 ms, and low steady-state overhead. The paper also contributes a programmable eBPF policy plane and a self-convergent multi-threading transition mechanism.

Significance. If the claims hold, KernelX would be a significant systems contribution: it turns compile-time kernel constants into millisecond-scale tunable knobs, goes beyond function-level live patching by offering side-effect safety, and opens a broad tuning space. The empirical coverage is a clear strength: 140 constants across four subsystems, 139 supported, with concrete real-workload case studies (FIO, RocksDB, NGINX) and careful attention to transition time and steady-state overhead. The use of standard mechanisms (kprobes, eBPF, kfuncs) makes the approach plausibly deployable. However, the 'any perf-const' universality claim is stronger than the evidence: the recovery procedure assumes, and by construction selects for, linear symbolic forms; safety rests on data-dependency thin slicing and on an unproven concurrency-safety property. These points need to be either formally justified, machine-checked, or explicitly scoped in the paper's claims.

major comments (4)
  1. [§3.3.2 (and §3.1, abstract)] The universality claim in the abstract and §3.1 is load-bearing and is not established. §3.3.1 asserts that a perf-const's effect 'always reduces to' R/M ← f(R/M, IV), and §3.3.2 recovers IV by fitting IV = a·V + b from compiled variants, while 'discards those [branches] that cannot preserve a linear relationship with V'. A constant used as a shift amount, divisor, table index, or inside an inlined expression that couples IV with another live value can yield a non-linear or multivariate expression. The paper states such cases were not observed, but no completeness argument is given; if such a case occurs, the pipeline either reports 'unsupported' or forces a linear approximation, violating the §3.4.1 invariant. The §7 exclusion of layout-changing constants and the Appendix C Kprobe failure further narrow the actual supported class. Please state the supported class precisely and validate
  2. [§3.5.1] Side-effect safety rests on the safety-span construction. §3.5.1 says the SS is a forward thin slice and that data dependencies are 'sufficient' based on empirical analysis; the safety invariant in §3.5 then asserts that no thread outside the SS retains a dependency on the old value. No proof or validation is given that control dependencies, aliased memory, or implicit state cannot carry stale effects. Since the paper's motivation is avoiding sysctl-style races and inconsistent state, this is load-bearing. I ask for a formal dependency-closure argument or an explicit restriction of the safety claim to data-dependent effects, plus a test that injects a transition at all SS exits and checks state against a rebuilt binary.
  3. [§7] The sequential equivalence invariant in §3.4.1 does not cover interleavings. §7 asserts that a CS is 'inherently concurrency-safe' because its instructions do not interleave with lock operations and cannot sleep or handle interrupts, but this is stated without proof. A synthesized SIE update modifies pt_regs or kernel memory from a kprobe context; another CPU, NMI, or interrupt handler can observe or modify the same location during the update. The 'no races' claim in §7 therefore requires a precise argument or an explicit mechanism (e.g., IRQ disabling or per-CPU restrictions) before it can support multi-threading safety.
  4. [§3.4.1 and §4] The correctness invariant at the end of §3.4.1 is stated but never discharged. There is no theorem, machine-checked proof, or runtime validation that the synthesized indirections satisfy Exec(σin, CSv∘I) ≡ Exec(σin, CSv′). The evaluation reports 139/140 successfully processed CSes and 82 with nontrivial IV (§6.1), but 'supported' appears to mean the pipeline generated probes, not that behavioral equivalence was verified. A single unsound rewrite would corrupt kernel state. Please add an automated differential check against a recompiled V′ kernel for every supported CS (or a formal proof of the synthesis algorithm) and report the results.
minor comments (6)
  1. [Abstract / §1] The abstract uses 'Xkernel' while the rest of the paper uses 'KernelX'; unify the name.
  2. [Various] Typos: 'throughout improvement' (§1); 'Symoblic' in §3.3.2 heading; 'increasd' in §5; 'cheaper cheaper' in Appendix B. Also Appendix C mentions both 'check_extent_items()' and 'check_extent_item()' for the same symbol.
  3. [§6.3, Figure 18] The text says the median latency for KLP and KernelX is 2.8 ms and 30.4 ms, respectively, and then claims this shows CS is more efficient than function-level transition. As written, KernelX is an order of magnitude slower; the labels/values or the sentence need correction.
  4. [§6.2] A 15% slowdown at 0 µs per operation (Figure 16) is described as 'negligible'; this is workload-dependent. State the operating region where the overhead is negligible rather than applying the term globally.
  5. [§1 and §9] The phrase 'any perf-const' should be qualified, e.g., 'any supported perf-const', given the exclusions in §7 and the Kprobe failure in Appendix C.
  6. [§3.3.2] The description of the linear-fit procedure is underspecified: it says two modified values are compiled and (V, IV) pairs are used to solve for a and b, but does not say how non-linearity is detected. Please specify the exact number of points and the detection criterion.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: SIE updates are transformation recovery, and the reported speedups are measured outcomes rather than predictions derived from the recovered expressions.

full rationale

The paper's core derivation chain is: (1) find seed instructions by rebuilding with alternate values, (2) recover a symbolic state expression R/M ← f(R/M, IV), (3) calibrate IV = a·V + b from two (V,IV) pairs, (4) synthesize indirections that rewrite R/M as if V′ were compiled in. None of these steps feeds a target result back into its own inputs. The IV→V linear fit is a compiler-transformation calibration, not a fit to the reported speedups; the correctness invariant ∀σin Exec(σin, CSv∘I) ≡ Exec(σin, CSv′) is a specification of correct state-update behavior, and the performance gains in Figures 1, 9–12 are measured end-to-end outcomes after applying updates, not predictions computed from the symbolic expressions. The main weaknesses are completeness risks, not circularity: §3.3.2 admits multivariate cases were 'not observed' and says branches that cannot preserve a linear relationship with V are discarded; §7 excludes layout-changing constants; Appendix C documents a Kprobe attachment failure. These bound the 'any perf-const' claim but do not make the derivation self-referential. Self-citations involving co-authors ([9], [30]) appear in related-work and Kprobe-implementation contexts and are not load-bearing substitutes for the paper's own evaluation.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

All central correctness and safety properties rest on a small number of unproved domain assumptions: compiler semantics remain numeric and recoverable; data dependencies are sufficient for safety; Kprobes are always available/reliable. The free parameters are the two calibration points used to recover IV→V; these are not benchmark fitting but are still hand-chosen inputs. No new physical or ontological entities are postulated; SIE, CS, and SS are implementation abstractions.

free parameters (2)
  • a,b in linear mapping IV = a·V + b = per-const interpolation from two rebuilt binaries
    KernelX compiles binaries with V' and V'' and solves for a,b; this assumes constant semantics remain linear. Nonlinear cases are declared unsupported rather than handled (§3.3.2).
  • V' and V'' (magic diff values) = hand-chosen per perf-const
    Used to generate the binary diff that locates seed instructions; a different choice could in principle change diff coverage and seed detection (§3.3.2).
assumptions (4)
  • domain assumption Compiler transformations preserve the numeric semantics of a perf-const such that its only runtime effect is captured by a convergent symbolic state expression of the form R/M ← f(R/M, IV).
    Introduced in §3.3.1 and relied on for all CS synthesis; the authors observe 140 cases but provide no general proof.
  • ad hoc to paper Data-dependency (thin-slice) analysis is sufficient to encapsulate all side effects of a perf-const value; control dependencies or implicit state are negligible.
    §3.5.1: 'Our empirical analysis shows that data dependencies are sufficient in capturing the required safety of updating most perf-consts.' The word 'most' leaves a gap for arbitrary constants.
  • domain assumption Kprobe attachment and execution interception are always available and reliable at all required CS/SS boundaries, except for documented limitations.
    SIE runtime depends on Kprobes; Appendix C documents one failure due to symbol ambiguity, so there is no formal guarantee for all constants.
  • ad hoc to paper Critical spans are inherently concurrency-safe: their instructions do not interleave with lock-related operations and cannot sleep or handle interrupts.
    Stated in §7 without proof; if false, the claimed race-freedom of X-tune could break.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Xkernel: Principled Performance Tunability of Operating System Kernels." pith.science (2026). https://pith.science/paper/DU7HKVEL

@misc{pith2026251212530,
  author       = {Pith},
  title        = {Pith review of: Xkernel: Principled Performance Tunability of Operating System Kernels},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DU7HKVEL}},
  note         = {Machine review of arXiv:2512.12530}
}
read the original abstract

The Linux kernel is permeated with constant values that are critical to system performance. Many of these constants, referred to as perf-consts, are magic numbers with brittle assumptions on hardware and workloads. Unfortunately, there is no capability of in-situ tuning of perf-const values on deployed kernels. This paper rethinks OS performance tunability. We present Xkernel, a system that offers a safe, efficient, and programmable interface for in-situ tuning of any perf-consts directly on a running kernel. Xkernel transforms any perf-const into a tunable knob on demand using a novel approach called Scoped Indirect Execution (SIE). SIE captures precise binary boundaries where a perf-const enters system state and redirects control to synthesized instructions that update the state as if new values were used. Xkernel goes beyond version atomicity when updating perf-consts to guarantee side-effect safety, a property notably absent in existing kernel update mechanisms. Case studies on various OS subsystems demonstrate significant performance benefits of tuning perf-consts which is made possible by Xkernel.

Figures

Figures reproduced from arXiv: 2512.12530 by the authors.

Figure 1
Figure 1. Performance benefits of changing the value of a [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Overview of KernelX. clobbering near the original sites. Side-effects of the original value. The original value may have already propagated, producing side effects that the ker￾nel execution still depends on. A reboot clears these effects but is incompatible with our goal. We therefore must iden￾tify and detect when these side effects have dissipated so the new perf-const value can be applied safely at runtime. 3 Ke… view at source ↗
Figure 3
Figure 3. Symbolic expression derived from a perf-const [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (12 more)
Figure 4
Figure 4. Figure 4: Synthesized SIE indirections for various CSes. An [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 6
Figure 6. Figure 6: KernelX API. itors are implemented as kprobes [45], inserted at the entry and exists of each SS. These kprobes are used only during the transition. Once the transition is done, they are removed. Per-thread safety. Unlike KLP that implements timer￾based polling, KernelX…
Figure 7
Figure 7. Figure 7: An example of X-tune. User-written policy code is [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]
Figure 9
Figure 9. Figure 9: Cost-benefit tradeoff that can be tuned by changing values of MAX_SOFTIRQ_RESTART. 8 16 24 28 32 64 128 Value of Perf-Const 10 5 10 6 Delta Time (μs) P50 P90 P99 CPU Usage 0 50 100 CPU Usage (%) [PITH_FULL_IMAGE:figures/full_fig_p009_9.png]
Figure 13
Figure 13. Figure 13: Characteristics of the evaluated perf-consts The [PITH_FULL_IMAGE:figures/full_fig_p010_13.png]
Figure 14
Figure 14. Figure 14: Number of CS and SS per perf-const. shown in [PITH_FULL_IMAGE:figures/full_fig_p010_14.png]
Figure 17
Figure 17. Figure 17: Policy-update time. Best case: only one kprobe [PITH_FULL_IMAGE:figures/full_fig_p011_17.png]
Figure 18
Figure 18. Figure 18: Transition time of KernelX using CS versus [PITH_FULL_IMAGE:figures/full_fig_p011_18.png]
Figure 20
Figure 20. Figure 20: The impact of SS size with global consistency. [PITH_FULL_IMAGE:figures/full_fig_p012_20.png]
Figure 21
Figure 21. Figure 21: Evolution of sysctl knobs. Each box shows the status of a knob. constant: a fixed perf-const in the source code; sysctl: exposed as a sysctl knob. per-domain: the sysctl knob is made per namespace. buggy: time between the introduction of a bug and the commit that fixe…
Figure 24
Figure 24. Figure 24: An X-tune for zswap shrinker; it only applies to [PITH_FULL_IMAGE:figures/full_fig_p017_24.png]
Figure 25
Figure 25. Figure 25: shows an X-tune that coordinates with other Kprobes to implement a more complex policy. #define MERGE_FAIL_THRESHOLD 16 struct { // Filled by blk_attempt_plug_merge() __uint(type, BPF_MAP_TYPE_TASK_STORAGE); __uint(map_flags, BPF_F_NO_PREALLOC); __type(key, int); __ty…

Discussion (0). Sign in to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. TuxBot: Semantic-Aware Online OS Tuning with Large Language Models

    cs.OS 2026-05 unverdicted novelty 7.0 of 10

    SemaTune uses LLM guidance with semantic context to tune up to 41 Linux OS parameters, delivering 72.5% performance gains over defaults and 153.3% over non-LLM baselines on 13 workloads while avoiding degraded states.

  2. Breaking Memory Bottlenecks in Quantum Control Systems for More Precise Experiments and Higher Throughput Computing

    cs.AR 2026-08 conditional novelty 6.0 of 10

    Ant-Q pipelines quantum circuit loading, execution, and readout uplink on FPGA control boards using a DRAM plus BRAM hierarchy, supporting deep randomized benchmarking circuits and reducing classical overhead to near zero.

Reference graph

Works this paper leans on

78 extracted references · 2 linked inside Pith · cited by 2 Pith papers

  1. [1]

    A RNOLD , J., AND KAASHOEK , M. F. Ksplice: Automatic Rebootless Kernel Updates. In Proceedings of the EuroSys Conference (EuroSys ’09) (April 2009)

    2009

  2. [2]

    C., A RPACI -DUSSEAU , R

    A RPACI -DUSSEAU , A. C., A RPACI -DUSSEAU , R. H., B UR- NETT , N. C., D ENEHY , T. E., E NGLE , T. J., G UNAWI , H. S., N UGENT , J. A., AND POPOVICI , F. I. Transform- ing policies into mechanisms with infokernel. In Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP ’03) (October 2003)

    2003

  3. [3]

    Explicit block device plugging

    A XBOE , J. Explicit block device plugging. https://lwn. net/Articles/438256/

  4. [4]

    Fio – flexible I/O tester

    A XBOE , J. Fio – flexible I/O tester. https://github.com/ axboe/fio

  5. [5]

    Linux kernel commit – block: bump max plugged deferred size from 16 to 32

    A XBOE , J. Linux kernel commit – block: bump max plugged deferred size from 16 to 32. https://github.com/torvalds/linux/commit/ ba0ffdd8ce48ad7f7e85191cd29f9674caca3745

  6. [6]

    W., AND KERR , J

    B AUMANN , A., H EISER , G., A PPAVOO, J., D A SILVA, D., KRIEGER , O., W ISNIEWSKI , R. W., AND KERR , J. Provid- ing dynamic update in an operating system. In Proceedings of the USENIX Annual Technical Conference (USENIX ’05) (April 2005)

    2005

  7. [7]

    TCP-BPF: Programmatically tuning TCP be- havior through BPF

    B RAKMO , L. TCP-BPF: Programmatically tuning TCP be- havior through BPF. In The Technical Conference on Linux Networking (NetDev 2.2) (November 2017)

    2017

  8. [8]

    Live updating operating systems using virtualization

    C HEN , H., C HEN , R., Z HANG , F., ZANG , B., AND YEW, P.- C. Live updating operating systems using virtualization. In Proceedings of the 2nd International Conference on Virtual Execution Environments (VEE ’06) (June 2006)

    2006

Show all 78 references
  1. [9]

    eTran: Extensible kernel transport with eBPF

    C HEN , Z., M ENG , Q., L AO, C., L IU, Y., R EN, F., Y U, M., AND ZHOU , Y. eTran: Extensible kernel transport with eBPF. In Proceedings of the 22nd USENIX Symposium on Networked Systems Design and Implementation (NSDI ’25) (April 2025)

    2025

  2. [10]

    5.19 fixes tags and the commits they fix

    C ORBET , J. 5.19 fixes tags and the commits they fix. https: //lwn.net/Articles/902938/

  3. [11]

    A rough patch for live patching

    C ORBET , J. A rough patch for live patching. https://lwn. net/Articles/634649/

  4. [12]

    Linux kernel commit – f2fs: increase the limit for reserve_root

    D ALTON , A., Y U, C., AND KIM, J. Linux kernel commit – f2fs: increase the limit for reserve_root. https://github.com/torvalds/linux/commit/ da35fe96d12d15779f3cb74929b7ed03941cf983

  5. [13]

    S., AND ZWAENEPOEL , W

    D RUSCHEL , P., PAI, V. S., AND ZWAENEPOEL , W. Extensi- ble kernels are leading OS research astray. InThe Sixth Work- shop on Hot Topics in Operating Systems (HotOS VI) (May 1997)

    1997

  6. [14]

    An ar- gument for increasing TCP’s initial congestion window.ACM SIGCOMM Computer Communication Review 40 , 3 (June 2010), 26–33

    D UKKIPATI , N., R EFICE , T., C HENG , Y., C HU, J., H ER- BERT, T., A GARWAL , A., J AIN , A., AND SUTIN , N. An ar- gument for increasing TCP’s initial congestion window.ACM SIGCOMM Computer Communication Review 40 , 3 (June 2010), 26–33

    2010

  7. [15]

    D UMAZET , E., AND MILLER , D. S. Linux ker- nel commit – tcp_cubic: refine Hystart delay thresh- old. https://github.com/torvalds/linux/commit/ 42eef7a0bb0989cd50d74e673422ff98a0ce4d7b

  8. [16]

    D UMAZET , E., AND MILLER , D. S. Linux kernel com- mit – tcp_cubic: switch bictcp_clock() to usec resolu- tion. https://github.com/torvalds/linux/commit/ cff04e2da308c522f654237b45dd64248fe8d1fa

  9. [17]

    D UYCK , A., D UMAZET , E., AND MILLER , D. S. Linux kernel commit – net: allow gso_max_size to exceed 65536. https://github.com/torvalds/linux/commit/ 7c4e983c4f3cf94fcd879730c6caa877e0768a4d

  10. [18]

    F ACEBOOK . RocksDB. http://rocksdb.org/

  11. [19]

    BMC: Accelerating memcached using safe in- kernel caching and pre-stack processing

    G HIGOFF , Y., S OPENA , J., L AZRI , K., B LIN , A., AND MULLER , G. BMC: Accelerating memcached using safe in- kernel caching and pre-stack processing. In Proceedings of the 18th Symposium on Networked Systems Design and Im- plementation (NSDI ’21) (April 2021)

    2021

  12. [20]

    G IUFFRIDA , C., K UIJSTEN , A., AND TANENBAUM , A. S. Safe and automatic live update for operating systems. In Proceedings of the 18th International Conference on Archi- tectural Support for Programming Languages and Operating Systems (ASPLOS ’13) (March 2013)

    2013

  13. [21]

    Dynamic re- structuring in an experimental operating system

    G OULLON , H., I SLE , R., AND LÖHR , K.-P. Dynamic re- structuring in an experimental operating system. IEEE Trans- actions on Software Engineering SE-4 , 4 (July 1978), 298– 307

    1978

  14. [22]

    Systems performance: enterprise and the cloud

    G REGG , B. Systems performance: enterprise and the cloud . Pearson Education, 2014

    2014

  15. [23]

    Linux kernel commit – tcp_cubic: make the delay threshold of HyStart less sensitive

    H A, S. Linux kernel commit – tcp_cubic: make the delay threshold of HyStart less sensitive. https://github.com/torvalds/linux/commit/ 2b4636a5f8ca547000f6aba24ec1c58f31f4a91d

  16. [24]

    H A, S., AND MILLER , D. S. Linux ker- nel commit – [TCP] CUBIC v2.3. https: //github.com/torvalds/linux/commit/ ae27e98a51526595837ab7498b23d6478a198960. 13

  17. [25]

    Hybrid slow start for high-bandwidth and long-distance networks

    H A, S., AND RHEE , I. Hybrid slow start for high-bandwidth and long-distance networks. In Proceedings of the Sixth In- ternational Workshop on Protocols for FAST Long-Distance Networks (PFLDnet ’08) (March 2008)

    2008

  18. [26]

    M., S MITH , E

    H AYDEN , C. M., S MITH , E. K., D ENCHEV , M., H ICKS , M., AND FOSTER , J. S. Kitsune: efficient, general-purpose dynamic software updating for C. In ACM SIGPLAN Inter- national Conference on Object-Oriented Programming, Sys- tems, Languages, and Applications (OOPSLA ’12) (O...

    2012

  19. [27]

    sched_ext schedulers and tools

    H EO, T. sched_ext schedulers and tools. https://github. com/sched-ext/scx

  20. [28]

    IOCost: Block IO Con- trol for Containers in Datacenters

    H EO, T., S CHATZBERG , D., N EWELL , A., L IU, S., D HAK - SHINAMURTHY , S., N ARAYANAN , I., B ACIK , J., M ASON , C., TANG , C., AND SKARLATOS , D. IOCost: Block IO Con- trol for Containers in Datacenters. In Proceedings of the 27th International Conference on Architectural...

    2022

  21. [29]

    D., B ORKMANN , D., F ASTABEND , J., H ERBERT , T., A HERN , D., AND MILLER , D

    H ØILAND -JØRGENSEN , T., B ROUER , J. D., B ORKMANN , D., F ASTABEND , J., H ERBERT , T., A HERN , D., AND MILLER , D. The eXpress data path: fast programmable packet processing in the operating system kernel. In Proceed- ings of the 14th International Conference on Emerging ...

    2018

  22. [30]

    Fast (Trapless) Kernel Probes Everywhere

    J IA, J., L E, M., A HMED , S., W ILLIAMS , D., J AMJOOM , H., AND XU, T. Fast (Trapless) Kernel Probes Everywhere. In Proceedings of the USENIX Annual Technical Conference (USENIX ’24) (July 2024)

    2024

  23. [31]

    T., M AZIÈRES , D., AND KOZYRAKIS , C

    K AFFES , K., H UMPHRIES , J. T., M AZIÈRES , D., AND KOZYRAKIS , C. Syrup: User-defined scheduling across the stack. In Proceedings of the 27th ACM Symposium on Oper- ating Systems Principles (SOSP ’21) (October 2021)

    2021

  24. [32]

    LlamaTune: sample-efficient DBMS configuration tuning

    K ANELLIS , K., D ING , C., K ROTH , B., M ÜLLER , A., CURINO , C., AND VENKATARAMAN , S. LlamaTune: sample-efficient DBMS configuration tuning. arXiv preprint arXiv:2203.05128 (2022)

    2022 arXiv

  25. [33]

    Striking the right chord: Parameter tuning in memory tiering systems

    K ANELLIS , K., Y ADALAM , S., V ENKATARAMAN , S., AND SWIFT , M. Striking the right chord: Parameter tuning in memory tiering systems. In Proceedings of the 3rd Workshop on Disruptive Memory Systems (DIMES ’25) (October 2025)

    2025

  26. [34]

    A., ZHAO, Y., AND RANGANATHAN , P

    L AGAR -CAVILLA , A., A HN, J., S OUHLAL , S., A GARWAL , N., B URNY, R., B UTT, S., C HANG , J., C HAUGULE , A., DENG , N., S HAHID , J., T HELEN , G., Y URTSEVER , K. A., ZHAO, Y., AND RANGANATHAN , P. Software-Defined Far Memory in Warehouse-Scale Computers. In Proceedings ...

    2019

  27. [35]

    it just happens to work well, that’s all

    L I, S. Linux kernel source comment: “it just happens to work well, that’s all.”. https://elixir.bootlin.com/linux/ v6.14/source/mm/swap_state.c#L587

  28. [36]

    Linux kernel commit – blk-throttle: choose a small throtl_slice for SSD

    L I, S., AND AXBOE , J. Linux kernel commit – blk-throttle: choose a small throtl_slice for SSD. https://github.com/torvalds/linux/commit/ d61fcfa4bb18992dc8e171996808e1034dc643bb

  29. [37]

    Linux kernel com- mit – block: avoid building too big plug list

    L I, S., AND AXBOE , J. Linux kernel com- mit – block: avoid building too big plug list. https://github.com/torvalds/linux/commit/ 55c022bbddb2c056b5dff1bd1b1758d31b6d64c9

  30. [38]

    An Expert in Residence: LLM Agents for Always-On Operating System Tuning

    L IARGKOVAS , G., J ABRAYILOV , V., F RANKE , H., AND KAFFES , K. An Expert in Residence: LLM Agents for Always-On Operating System Tuning. In Workshop on ML for Systems at NeurIPS (December 2025)

    2025

  31. [39]

    S., AND KAFFES , K

    L IARGKOVAS , G., S ODHI , P. S., AND KAFFES , K. Set it and forget it: Zero-mod ML magic for Linux tuning. In Proceed- ings of the 4th Workshop on Practical Adoption Challenges of ML for Systems (PACMI ’25) (October 2025)

    2025

  32. [40]

    StorageXTuner: An LLM agent-driven auto- matic tuning framework for heterogeneous storage systems

    L IN, Q., Z HANG , Z., T HAKKAR , V., S UN, Z., Z HENG , M., AND CAO, Z. StorageXTuner: An LLM agent-driven auto- matic tuning framework for heterogeneous storage systems. arXiv preprint arXiv:2510.25017 (2025)

    2025

  33. [41]

    ABI stable symbols

    L INUX DEVELOPERS . ABI stable symbols. https://www.kernel.org/doc/html/v6.14/admin- guide/abi-stable.html

  34. [42]

    BPF kernel functions (kfuncs)

    L INUX DEVELOPERS . BPF kernel functions (kfuncs). https://www.kernel.org/doc/html/v6.14/bpf/ kfuncs.html

  35. [43]

    Git blame of SHRINK_BATCH: fixed value since 2005

    L INUX DEVELOPERS . Git blame of SHRINK_BATCH: fixed value since 2005. https://github.com/torvalds/linux/blame/ e538a582097878c536c68002c79722e4a037c080/mm/ vmscan.c#L832

    2005

  36. [44]

    Kconfig language

    L INUX DEVELOPERS . Kconfig language. https:// www.kernel.org/doc/html/v6.14/kbuild/kconfig- language.html

  37. [45]

    Kernel Probes (Kprobes)

    L INUX DEVELOPERS . Kernel Probes (Kprobes). https://www.kernel.org/doc/html/v6.14/trace/ kprobes.html

  38. [46]

    Kprobes preserve kernel-state context

    L INUX DEVELOPERS . Kprobes preserve kernel-state context. https://elixir.bootlin.com/linux/v6.14/ source/tools/lib/bpf/bpf_tracing.h#L813

  39. [47]

    Livepatch

    L INUX DEVELOPERS . Livepatch. https://www.kernel. org/doc/html/v6.14/livepatch/livepatch.html

  40. [48]

    Perf-const in tcp_sendmsg_locked

    L INUX DEVELOPERS . Perf-const in tcp_sendmsg_locked. https://elixir.bootlin.com/linux/v6.14/source/ net/ipv4/tcp.c#L1162

  41. [49]

    L INUX DEVELOPERS . zswap. https://www.kernel.org/ doc/html/v6.14/admin-guide/mm/zswap.html

  42. [50]

    The filesystem for export- ing kernel objects

    M OCHEL , P., AND MURPHY , M. The filesystem for export- ing kernel objects. https://www.kernel.org/doc/html/ v6.14/filesystems/sysfs.html, 2003

    2003

  43. [51]

    f4: Facebook’s warm BLOB storage system

    M URALIDHAR , S., L LOYD , W., ROY, S., H ILL , C., L IN, E., LIU, W., P AN, S., S HANKAR , S., S IVAKUMAR , V., T ANG , L., AND KUMAR , S. f4: Facebook’s warm BLOB storage system. In Proceedings of the 11th Symposium on Operat- ing Systems Design and Implementation (OSDI ’14)...

    2014

  44. [52]

    Linux kernel commit – block, bfq: boost throughput by extending queue-merging times

    P EDRONI , P., V ALENTE , P., AND AXBOE , J. Linux kernel commit – block, bfq: boost throughput by extending queue-merging times. https://github.com/torvalds/linux/commit/ 7812472f973047a886e4ed9a91d98d6627dd746f

  45. [53]

    ZygOS: Achieving low tail latency for microsecond-scale networked tasks

    P REKAS , G., K OGIAS , M., AND BUGNION , E. ZygOS: Achieving low tail latency for microsecond-scale networked tasks. In Proceedings of the 26th ACM Symposium on Oper- ating Systems Principles (SOSP ’17) (October 2017)

    2017

  46. [54]

    R AYHAN , Y., AND AREF, W. G. Revisiting page mi- gration for main-memory database systems. arXiv preprint arXiv:2503.17685 (2025)

    2025 arXiv

  47. [55]

    Discussions on kpatch bugs and limitations

    R ED HAT. Discussions on kpatch bugs and limitations. https://github.com/dynup/kpatch/pull/1355

  48. [56]

    kpatch: dynamic kernel patching

    R ED HAT. kpatch: dynamic kernel patching. https:// github.com/dynup/kpatch

  49. [57]

    From Global to Local Quiescence: Wait-Free Code Patching of Multi-Threaded Processes

    R OMMEL , F., D IETRICH , C., F RIESEL , D., K ÖPPEN , M., B ORCHERT , C., M ÜLLER , M., S PINCZYK , O., AND LOHMANN , D. From Global to Local Quiescence: Wait-Free Code Patching of Multi-Threaded Processes. In Proceedings of the 14th USENIX Conference on Operating Systems Des...

    2020

  50. [58]

    Cyclictest

    RT-T ESTS DEVELOPER TEAM . Cyclictest. https://wiki. linuxfoundation.org/realtime/documentation/ howto/tools/cyclictest/start

  51. [59]

    S ALTZER , J., AND KAASHOEK , M. F. Principles of Com- puter System Design: an Introduction . Morgan Kaufmann, 2009

    2009

  52. [60]

    Reverse engineering feature models

    S HE, S., L OTUFO , R., B ERGER , T., W ˛ ASOWSKI, A., AND CZARNECKI , K. Reverse engineering feature models. In Pro- ceedings of the 33rd International Conference on Software Engineering (ICSE ’11) (May 2011)

    2011

  53. [61]

    J., AND BODÍK , R

    S RIDHARAN , M., F INK , S. J., AND BODÍK , R. Thin Slic- ing. In Proceedings of the ACM SIGPLAN 2007 Confer- ence on Programming Language Design and Implementation (PLDI’07) (June 2007)

    2007

  54. [62]

    kgraft: Live patching of the Linux ker- nel

    SUSE. kgraft: Live patching of the Linux ker- nel. https://events.static.linuxfound.org/sites/ events/files/slides/kGraft.pdf

  55. [63]

    Static analysis of variability in system software: The 90,000 #ifdefs issue

    T ARTLER , R., D IETRICH , C., S INCERO , J., S CHRÖDER - PREIKSCHAT , W., AND LOHMANN , D. Static analysis of variability in system software: The 90,000 #ifdefs issue. In Proceedings of the USENIX Annual Technical Conference (USENIX ’14) (June 2014)

    2014

  56. [64]

    Feature consistency in compile-time–configurable system software: Facing the Linux 10,000 feature problem

    T ARTLER , R., L OHMANN , D., S INCERO , J., AND SCHRÖDER -P REIKSCHAT , W. Feature consistency in compile-time–configurable system software: Facing the Linux 10,000 feature problem. In Proceedings of the EuroSys Conference (EuroSys ’11) (April 2011)

    2011

  57. [65]

    Can modern LLMs tune and configure LSM-based key-value stores? In 16th ACM Workshop on Hot Topics in Storage and File Systems (HotStorage ’24) (July 2024)

    T HAKKAR , V., S UKUMAR , M., D AI, J., S INGH , K., AND CAO, Z. Can modern LLMs tune and configure LSM-based key-value stores? In 16th ACM Workshop on Hot Topics in Storage and File Systems (HotStorage ’24) (July 2024)

    2024

  58. [66]

    iperf3: A TCP, UDP, and SCTP net- work bandwidth measurement tool

    T HE IPERF 3 AUTHORS . iperf3: A TCP, UDP, and SCTP net- work bandwidth measurement tool. https://github.com/ esnet/iperf

  59. [67]

    Data race vulnerability in Linux ker- nel: sysctl access issue

    T HE VULERT TEAM. Data race vulnerability in Linux ker- nel: sysctl access issue. https://vulert.com/vuln-db/ debian-11-linux-289447

  60. [68]

    Linux-2.6.12-rc2: Let it rip

    T ORVALDS , L. Linux-2.6.12-rc2: Let it rip. https://github.com/torvalds/linux/commit/ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, 2005

    2005

  61. [69]

    KernelCare: Rebootless security patching with zero downtime

    T UXCARE. KernelCare: Rebootless security patching with zero downtime. https://tuxcare.com/enterprise- live-patching-services/kernelcare-enterprise/

  62. [70]

    Linux kernel commit – block, bfq: reduce threshold for detecting command queue- ing

    V ALENTE , P., AND AXBOE , J. Linux kernel commit – block, bfq: reduce threshold for detecting command queue- ing. https://github.com/torvalds/linux/commit/ a3c92560324bd616deaecb6842b2a0337a80ad8b

  63. [71]

    Linux kernel commit – block, bfq: reduce write overcharge

    V ALENTE , P., AND AXBOE , J. Linux kernel commit – block, bfq: reduce write overcharge. https://github.com/torvalds/linux/commit/ d5801088a7bd210dd8fd7add04745e35f0f6ea72

  64. [72]

    Documentation for /proc/sys

    VAN RIEL , R. Documentation for /proc/sys. https://www.kernel.org/doc/html/v6.14/admin- guide/sysctl/index.html, 1999

    1999

  65. [73]

    C., AND KEE- TON , K

    Y ELAM , A., W U, K., G UO, Z., Y ANG , S., S HASHIDHARA , R., X U, W., N OVAKOVIC , S., S NOEREN , A. C., AND KEE- TON , K. PageFlex: flexible and efficient user-space dele- gation of Linux paging policies with eBPF. In Proceedings of the USENIX Annual Technical Conference (U...

    2024

  66. [74]

    Linux kernel commit – migrate_pages: restrict number of pages to migrate in batch

    Y ING , H. Linux kernel commit – migrate_pages: restrict number of pages to migrate in batch. https://github.com/torvalds/linux/commit/ 42012e0436d44aeb2e68f11a28ddd0ad3f38b61f

  67. [75]

    tcp: Set pingpong threshold via sysctl

    Z HANG , H. tcp: Set pingpong threshold via sysctl. https://github.com/torvalds/linux/commit/ 562b1fdf061bff9394ccd884456ed1173c224fdc

  68. [76]

    J., Z ARKADAS , I., T AO, J., M ESTERHAZY , E., M AKRIS , M., Y ANG , J., T AI, A., STUTSMAN , R., AND CIDON , A

    Z HONG , Y., L I, H., W U, Y. J., Z ARKADAS , I., T AO, J., M ESTERHAZY , E., M AKRIS , M., Y ANG , J., T AI, A., STUTSMAN , R., AND CIDON , A. XRP: In-Kernel storage functions with eBPF. In Proceedings of the 16th USENIX Conference on Operating Systems Design and Implementa- ...

    2022

  69. [77]

    Linux kernel commit – mm: per device dirty threshold

    Z IJLSTRA , P., D ICKINS , H., M ORTON , A., AND TORVALDS , L. Linux kernel commit – mm: per device dirty threshold. https: //github.com/torvalds/linux/commit/ 04fbfdc14e5f48463820d6b9807daa5e9c92c51f

  70. [78]

    maps"); X_TUNE(blk_add_rq_to_plug,

    Z USSMAN , T., Z ARKADAS , I., C ARIN , J., C HENG , A., FRANKE , H., P FEFFERLE , J., AND CIDON , A. cache_ext: Customizing the page cache with eBPF. In Proceedings of the 30th ACM Symposium on Operating Systems Principles (SOSP ’25) (October 2025). 15 A Sysctl Performance Kn...

    2025

Pith tools

Reviewed August 3, 2026 · model on record in the stance chip above.