Report — AI for Systems, outside the fashionable subsystems

Second pass, 26 August 2026. Verbatim, including its own verification caveats.

Areas checked: learned decisions in unfashionable kernel subsystems; LLM Kconfig minimization; LLMs for stable-tree maintenance; LLM-assisted test selection and CI triage; performance-bug localization and bisection; LLM-generated or LLM-checked kernel API specifications; unclaimed accounting-audit niches; anything else GPU-free.

Explicitly excluded as already-checked: learned cache replacement (3L-Cache, S4-FIFO, SIEVE), learned CPU scheduling via sched_ext, LLM-guided kernel fuzzing, LLM synthesis of verified eBPF, learned memory tiering (PACT, Memtis, TPP).

---

Headline: seven of eight areas are more crowded than assumed, and the two that survive are not the ones you would guess. The one genuinely strong finding is area 6 (LLM-inferred kernel locking/context annotations), where the incumbent tooling states in its own documentation that it cannot do inference and requires hand annotation. Areas 3, 4 and 5 have real gaps and read unambiguously as Software Engineering, which for a Computer Engineering department is a topic-selection problem rather than a research problem.

Three claims below rest only on absence of search hits and are flagged each time: learned writeback throttling, ML for khugepaged collapse decisions, and the absence of any published evaluation of AUTOSEL. Everything else has a named occupant. Unrefereed preprints are marked explicitly, because roughly a third of the 2026 citations here are arXiv-only.

---

Area 1 — Learned decisions in less-fashionable kernel subsystems

This area needs splitting: the eight subsystems have wildly different occupancy, and lumping them together is what makes the area look open.

1a. Block-layer I/O — crowded

The most occupied item in the entire candidate list, and occupied by exactly the work you would want to do.

• Heimdall: Optimizing Storage I/O Admission with Extensive Machine Learning Pipeline — EuroSys 2025. artifact · PDF. ML I/O admission with a full pipeline (period-based labeling, three-stage noise filtering, feature engineering, hyperparameter tuning); 93–99% accuracy, 15–35% average latency reduction, sub-microsecond inference via manual Python-to-C conversion plus quantization, 28 KB memory, deployed in the Linux block layer and Ceph, evaluated on Microsoft, Alibaba and Tencent production traces.
• Towards a Machine Learning-Assisted Kernel with LAKE — ASPLOS 2023. DOI. Surveys ML replacement of heuristics across five kernel subsystems, builds the in-kernel accelerator-access framework, and reports the finding that pre-empts most of this area: the benefit of ML in kernels is subsystem-, workload- and hardware-dependent.
• ADIOS (Adaptive Deadline I/O Scheduler) — out-of-tree, GitHub. Learns a per-device latency model (base latency plus size slope) and adjusts deadlines. Not a paper, but the "someone already shipped it" baseline.
• LinnOS (OSDI 2020, UChicago, same group as Heimdall) is the canonical predecessor — light neural network for flash latency prediction. Recalled rather than verified in this pass; check before citing.

Surviving gap? Heimdall assumes the decision is admission and charges itself honestly for inference. It does not do request ordering — the mq-deadline/BFQ/Kyber decision. But that inverse is closed from the other side: BFQ, Multiqueue-Deadline, or Kyber? Performance Characterization of Linux Storage Schedulers in the NVMe Era — ICPE 2024, PDF — establishes that on NVMe the correct answer is frequently none, i.e. no software scheduling at all. A learned scheduler must beat "do nothing," which is free and has zero overhead.

Reviewer sentence: "Heimdall already showed disciplined data science gets sub-µs in-kernel inference; what is new?" Reads as: Operating Systems.

1b. Readahead and prefetch policy — crowded

• Improving Storage Systems Using Machine Learning (KML) — ACM Transactions on Storage, 2023. DOI · PDF. Stony Brook. Readahead is case study #1 and NFS rsize is case study #2. Neural nets and decision trees inside kernel 4.19, <4 KB dynamic kernel memory, <0.2% CPU overhead, 2.3× and 15× throughput. Earlier position paper: HotStorage 2021, NSF PAR.
• Neural Storage Driver (NSD) — RFC PATCH, LKML, 25 July 2026. thread. Learning page-cache prefetcher, synaptic Markov chain over 4 KB regions, hooks filemap_read(), 98% prefetch hit rate, +22.6% sequential throughput, −18.8% SQLite FTS query time. Unrefereed, single-author RFC on a 7.0.0 kernel, ~480 lines, no upstream traction visible. Treat as a hobbyist patch, not a competitor — but a reviewer will find it, and it takes the obvious title.

Surviving gap? Narrow. KML tunes the readahead value under changing workloads; it does not replace the fixed-window algorithm. NSD does, badly. There is room for "does a learned prefetcher beat the fixed window once you charge it," but that is the 3L-Cache move already ruled out, transplanted one subsystem over.

1c. CPU frequency governor policy — crowded

• CPU frequency scheduling of real-time applications on embedded devices with temporal encoding-based deep reinforcement learning — Journal of Systems Architecture, 2023. DOI · PDF. RL DVFS governor using the same single performance counter as the built-in governor, 3–14% energy improvement over ondemand, and it open-sourced an in-kernel quantized neural network engine (tinyagent). The MVP with the infrastructure already released.
• Energy-Efficient Computation with DVFS using Deep Reinforcement Learning for Multi-Task Systems in Edge Computing — arXiv 2409.19434. DDQN, multi-task, Jetson Nano, 3–10%.
• ZeroDVFS: Zero-Shot LLM-Guided Core and Frequency Allocation for Embedded Platforms — arXiv 2601.08166. Preprint, venue unconfirmed. Hierarchical MARL plus LLM semantic feature extraction from OpenMP source, 7.09× energy efficiency over ondemand across four boards.

Surviving gap? The incumbents all beat ondemand, while schedutil — running inside the scheduler on PELT metrics with I/O-wait boost and RT ramp-to-max — is the actual default on modern distros. So there is a live "everybody benchmarked the wrong baseline" critique. It is thin, and it collides with the sched_ext topic: scx_lavd already carries an energy model and core compaction, so a frequency thesis and a placement thesis are now the same thesis.

Rejection vocabulary: "incremental within a saturated literature" — this is a fifteen-year-old embedded genre with hundreds of entries.

1d. TCP congestion-control selection — crowded, and drop it

Genuinely dead for a masters, and a networking topic rather than an OS one.

• Mutant: Learning Congestion Control from Existing Protocols via Online Reinforcement Learning — NSDI 2025. PDF. Online RL adapting to whichever existing scheme is best; explicitly the "select among CCAs" framing.
• Antelope: A Machine Learning-Based Framework for Dynamic Selection of Congestion Control Algorithms — IEEE/ACM Transactions on Networking, 2022. DOI.
• Astraea: Towards Fair and Efficient Learning-based Congestion Control — EuroSys 2024. DOI.
• Computers Can Learn from the Heuristic Designs and Master Internet Congestion Control (Orca lineage) — SIGCOMM 2023. DOI.
• HTPCCS — IEEE BigDataSE 2025. DOI. Thompson-sampling contextual bandit over a curated CCA set. The "selection" MVP, line for line.
• LACC — IEEE TNSM 2025. DOI. Switches only when the current CCA is unsuitable; −31% overhead. Even the "don't thrash the selector" refinement is taken.

Plus a 2021 survey (When machine learning meets congestion control, Computer Networks 192:108033) — a survey that old is itself the crowdedness signal.

1e. NUMA auto-balancing and hot-page promotion — active, being eaten upstream in real time

No ML paper occupies this, but the dynamic that killed the easy sched_ext thesis applies: production kernel engineering is consuming the contribution while you would be writing.

• pghot: Hot page tracking and promotion infrastructure — PATCH v8, LKML, 28 July 2026. thread · v8 5/8. AMD (Bharata B Rao). Moves promotion out of the scheduler into kmigrated, and moves the rate-limiting and dynamic-threshold logic with it so multiple hotness sources can share it. Threshold adaptation via a candidate-count feedback loop — a hand-tuned controller occupying precisely the slot a learned predictor would fill.
• PACT — ASPLOS 2026. Its headline claim, access frequency is the wrong signal, is the insight a learned promotion predictor would be claiming.

Surviving gap: pghot assumes a scalar hotness threshold adapted by a candidate-count feedback loop suffices to rank promotion candidates, and that does not hold when access recency and stall criticality disagree — which is PACT's finding, arrived at without learning. Real, but someone already walked through it non-learnedly.

1f. khugepaged / mTHP collapse decisions — open, weakest evidence in this report

• khugepaged: mTHP support — PATCH v17, mm-unstable, May 2026. LKML · LWN. Nico Pache. Bitmap over the PMD range plus binary recursion to choose collapse order.

No ML or LLM work on huge-page collapse decisions was found. That is absence of hits, not proof.

One genuinely attractive seam, stated by the incumbent itself: the series documents "collapse creep" — with max_ptes_none > HPAGE_PMD_NR/2 the collapse introduces at least 2× the non-zero pages, so the next scan satisfies the promotion condition again and mTHPs ratchet upward forever. The workaround is to forbid max_ptes_none values other than 0 or 511 and warn otherwise. So: khugepaged assumes a static per-order fullness threshold can separate worthwhile collapses from creep, and that assumption fails badly enough that the maintainers restricted the tunable to two values rather than solve it. A predictor of "will this collapse be retained or immediately re-collapsed" is well-posed, needs no GPU, and is measurable on one workstation.

Smallest defensible result. Instrument the mTHP collapse path, characterize how often collapses at each order are followed by re-collapse or immediate splitting under real workloads, then a cheap online predictor gating collapse per order. Hardware: one machine with an mTHP-capable kernel (6.13+), no GPU.

How it goes wrong. Your baseline is max_ptes_none=0, which is free and sidesteps creep entirely; you must show a workload where 0 leaves real TLB benefit on the table. Rejection vocabulary: "this is a tuning problem, and the maintainers already picked safe defaults." Also, mTHP is a fast-moving target — v17 means sixteen prior rounds of maintainer opinion to absorb.

Reads as: Operating Systems, cleanly. Best departmental fit in area 1.

1g. Writeback throttling and dirty-page balancing — open, on absence of evidence only

No learned or LLM work on balance_dirty_pages(), dirty ratelimiting, or flusher scheduling was found. Everything returned was kernel source, documentation, or tuning blog posts. The incumbent is Wu Fengguang's 2011 dirty-ratelimit controller (LKML) — a hand-derived feedback controller computing ref_bw = write_bw / N, still the design in mm/page-writeback.c fifteen years later, and still being patched for regressions in 2026 (stable thread, where fuse buffered writes dropped from 1400 MiB/s to 2000 KiB/s under a strictlimit/memcg interaction).

Surviving gap? Plausibly: the dirty-ratelimit controller assumes writeback bandwidth is estimable from a 200 ms trailing window and shared fairly across N symmetric dirtiers, and that does not hold under cgroup strictlimit with heterogeneous backing devices — which the 2026 regression demonstrates concretely.

But be skeptical of this. Two reasons it may be a mirage. Absence of hits is weak, and this is a subsystem where the relevant work might be a single unindexed LKML thread. And the tuning framing is already taken: SemaTune / TuxBot: Semantic-Aware Online OS Tuning with Large Language Models — arXiv 2605.15026. Preprint, venue unconfirmed, and note the same arXiv ID resolves under two different titles — a preprint-quality warning sign. Tunes 41 Linux knobs including the memory and I/O domains across 13 workloads, +72.5% over defaults, +153.3% over the strongest non-LLM baseline, ~$0.20 per 30-window session. The vm.dirty_* knobs are almost certainly inside its tunable set. So "learn the dirty thresholds" is claimed; "replace the ratelimit controller" is not.

How it goes wrong. Writeback is where the kernel's most brutal user-visible latency bugs live, and any change risks the exact D-state stalls the current design exists to prevent. A negative result is very likely, and the heuristic has had fifteen years of production hardening.

---

Area 2 — LLM-driven Kconfig minimization and attack-surface reduction

Rating: crowded. Owned twice over: by a refereed non-LLM paper from December 2025 and by an LLM preprint from August 2026.

• In Pursuit of Lean OS Kernels: Improving Configuration-Based Debloating — ACSAC 2025 (8 Dec 2025). DOI. Presents Tracie (trace-based, 21.67% reduction, +8% over prior work, 1 extra CVE removed) and Dice (trace-free, dependency-aware graph pruning, 35.59% reduction, 10 more CVEs eliminated). Crucially it closes with the negative result that kills the LLM pitch: an empirical analysis of Kconfig showing that structural limitations — coarse granularity and rigid dependencies — cap what configuration-based debloating can achieve at all. If the ceiling is structural, a smarter chooser does not raise it.
• Inferring 1-Minimal Trigger Configurations for Assessing Linux Kernel CVE Triggerability (FCC) — arXiv 2608.15225 · code. Preprint, venue unconfirmed. LLM-powered three-stage pipeline: semantic profiling from NVD/CWE, LLM dependency completion over Kconfig and Makefiles under make olddefconfig feedback, then runtime-validated minimization to a 1-minimal set. Data for 88 CVEs from KernJC and KernelCTF.
• ICMOS: Incremental Concept Mining for OS Kernel Configuration via LLMs Agentic Reasoning — OpenReview. An OpenReview submission; acceptance and venue could not be confirmed — treat as unrefereed. LLM plus heterogeneous knowledge graph over 17,000+ options; halves optimization time, −58.1% tail latency, doubles configuration success rate on databases, web servers and caches.
• Pre-LLM foundations, all refereed: Set the Configuration for the Heart of the OS (Kuo, Chen, Mohan, Xu), SIGMETRICS/POMACS 2020, DOI; KASR, ESORICS 2018, DOI; Configuration-Driven Software Debloating, EuroSec 2019, DOI.

Surviving gap? Not usefully. The honest reading is that ACSAC 2025 pre-refuted the area: if kconfig granularity is the binding constraint, an LLM chooser trades against a bound it cannot move.

Strongest baseline: Dice, which is trace-free and needs no LLM. Reviewer vocabulary: "the reported gain is within the noise of dependency-graph pruning, and the ACSAC analysis shows the ceiling is structural." Reads as: Security / Software Engineering. Wrong department.

---

Area 3 — LLMs for stable-tree maintenance

Rating: active, with a real open slice, but it reads as SE.

The most interesting split in the list. Backport transformation is claimed. Backport selection is occupied by unevaluated production tooling.

Transformation (crowded):

• PortGPT: Towards Automated Backporting Using Large Language Models — arXiv 2510.22396. Preprint; no refereed venue confirmed — likely under submission to a security conference. GPT-4o agent with symbol lookup, git history and compiler-feedback refinement. 89.15% overall on 1,465 Linux CVEs from TSBPORT plus 350 bugs from FixMorph; 62.33% on a harder 146-case multi-language set; and post-cutoff validation on Linux 6.1-stable where 9 of 18 backports were accepted upstream by the Linux community.
• FixMorph: Automated Patch Backporting in Linux (Experience Paper) — ISSTA 2021. PDF. 75.1% of 350 mainline patches; the non-LLM baseline everyone reports against. (TSBPORT is cited by PortGPT as the other prior state of the art; its venue was not independently verified.)
• BackportBench: A Multilingual Benchmark for Automated Backporting of Patches — arXiv 2512.01396 · code. Preprint. 202 problems, Dockerized, test-driven FAIL_TO_PASS/PASS_TO_PASS. Note carefully: PyPI / Maven / npm — not the kernel. Its most useful finding is that Mystiqe often passed the vulnerability test while breaking existing functionality, i.e. prior syntactic-similarity metrics measured the wrong thing.
• Unpublished tooling: RetroPatch (GitHub, including a "prejudge" pipeline deciding whether a fix is worth backporting — the closest competitor on the selection problem), Canonical's PatchFlow (GitHub), and git_llm_pick.

Selection (the open slice):

• AUTOSEL — Sasha Levin (NVIDIA, co-maintainer of stable/LTS). source · LWN release note · The New Stack. Rust, embedding retrieval over historical commits, few-shot across multiple LLM providers with cross-validation, in production generating AUTOSEL review series per merge window. A CVE classifier is built on top.

No peer-reviewed evaluation of AUTOSEL, and no published precision/recall for stable-backport selection at all, was found. That is absence of hits — but unusually informative, because the pain point is documented in public: the LWN thread contains maintainers (Jakub Kicinski) asking for the reasoning to be exposed and worrying explicitly about "excessive false positives burdening humans," with Levin responding by injecting explanations under the --- separator. Levin himself reviews ~100 patches/day across multiple branches.

Surviving gap — well-formed: AUTOSEL assumes that a commit's embedding similarity to historically-backported commits predicts whether it should be backported, and that assumption is untested against the maintainer-cost metric that actually determines adoption — false positives per accepted patch. Nobody has published that number.

Smallest defensible result. Ground truth is free and enormous: for any merge window, the set of commits that actually landed in stable is in git metadata, and Fixes: tags plus later revert/regression commits give labels for both error directions. Reproduce AUTOSEL's selection over several historical merge windows and report precision, recall, and false positives per true positive — the quantity maintainers actually pay for — plus $/decision. Hardware: a kernel git clone and API credits. Zero GPU. The cheapest defensible result anywhere in this report.

How it goes wrong. Three ways, one fatal. (i) Your strongest baseline is embarrassing: Fixes: tag presence plus a keyword list may match an LLM at a millionth of the cost, and if it does, your thesis is a two-page note. (ii) Label noise — "should have been backported" is a maintainer judgement, not a fact, and Levin's own tooling found extras he had previously missed, so the ground truth is partly generated by the system you are auditing. (iii) It reads as Software Engineering, unambiguously. This is empirical software maintenance research: no OS mechanism, no kernel code written, no resource-management decision. A Computer Engineering committee will ask why it is not an MSR/ICSE paper, and the honest answer is that it is one.

---

Area 4 — LLM-assisted regression test selection and CI triage

Rating: crowded. Occupied from three directions: production (Google), a refereed kernel-specific empirical study, and the general SE literature.

• syzbot ci — Linux Plumbers Conference 2025. slides. Google. Auto-triage of patch series to base tree and subsystem, then focused fuzzing with prioritized seed selection (seeds covering changed object code first, then modified files, then the rest), only selected syscalls fuzzed, session aborted if no patched code is covered in 30 minutes, fuzzing skipped entirely if binaries are identical. It also publishes its own limitations: auto-triage fails on ~13% of series, recall is capped by needing reproducers, and coverage is capped by syzkaller's reach.
• An empirical study of test case prioritization on the Linux Kernel — ASE 2025 (journal-first). page. This is the study you would have proposed. 17 TCP techniques — similarity-based, IR-based, coverage-based — on the Linux kernel. Similarity-based wins (mean APFD 0.7583) and is cheapest; most techniques are stable across commits; and more than half are severely degraded by flaky tests, with APFD dropping 29.9% to 63.5%.
• Targeted Test Selection (T-TS) — arXiv 2509.10279. Preprint, but deployed industrially: bag-of-words over changed files, no coverage maps, selects 15% of tests, 5.9× faster execution, >95% failure detection.
• KNighter: Transforming Static Analysis with LLM-Synthesized Checkers — SOSP 2025. PDF. Also does LLM-assisted triage of its own warnings with an explicit cost discipline (sample 5 warnings per checker, ≤3 refinement iterations, and a stated concern about "hundreds of dollars per thorough scan").
• Facebook's predictive test selection is the industrial reference point (99.9% of regressions at 33% of tests, −84% execution time). Production kernel CI infrastructure: kdevops kernel-ci (docs) and NVIDIA's boro (GitHub), which already does model-picked targeted test selection under virtme-ng.

Surviving gap — one, named for you by the incumbent: ASE 2025 shows every studied TCP technique loses 30–63% of its fault-detection ability to flaky tests, and none of the techniques model flakiness. Flake-robust prioritization for kernel CI is unclaimed. But it is a small delta on a completed study, and the ASE authors are positioned to do it next.

Rejection vocabulary: "test case prioritization is a thirty-year-old field with standardized metrics (APFD), and the kernel-specific empirical question was answered at ASE 2025." Strongest baseline is similarity-based TCP, which is nearly free. Reads as Software Engineering.

---

Area 5 — LLM performance-bug localization and regression bisection

Rating: active for correctness bugs (crowded), open for performance bugs (thin).

The distinction matters and initial searches obscured it: the general "LLM bisect" hits were low-quality GitHub tooling for LLM-agent regressions (sornaris, rewind, halley), not systems code. Filtered:

Correctness-bug localization in the kernel — crowded, and refereed:

• Taming System Complexity: Demystifying Software Engineering Agents in Diagnosing Linux Kernel Faults (LinuxFLBench + LinuxFL+) — ACL 2026 Long. ACL Anthology · DOI · arXiv 2505.19489. Benchmark plus enhancement, both done. SWE-Agent, AutoCodeRover and Agentless all evaluated: best top-1 file-level accuracy 41.6%, a 16.7–31.9 point drop versus SWE-bench, and the union of all agents at top-1 only 58.4%. LinuxFL+ adds directory-aware expansion plus LKML-RAG cause expansion for +7.2–11.2 points.
• kAPR: A coverage-guided, context-aware agent for automated repair of Linux kernel bugs — Information and Software Technology, 2026. DOI. Recovers kCOV and ftrace records in the window between panic and reboot, computes suspiciousness, then runs a developer/maintainer dual-agent workflow.
• kAgent + kGym++ — arXiv 2504.20412. Preprint. 54.5% of crashes repaired without localization, 65% with file hints, on kBenchSyz.
• AutoDriver + DriveBench — arXiv 2511.18924. Preprint. Kernel→driver co-evolution, v5.10–v6.10, 235 cases, 56.4% compilation success with QEMU boot verification.
• Time Travel: LLM-Assisted Semantic Behavior Localization with Git Bisect — arXiv 2511.18854. Preprint. LLM classifies commits good/bad at each bisect step; 74.2% → 80.6% success, up to 2× fewer steps. Explicitly motivated by bisect's broken assumptions — determinism, monotonicity, binary predicates.

Performance bugs: every system above targets crashes, panics or functional faults. None targets throughput or latency regressions. So the gap is real: "Time Travel" assumes a commit can be classified good or bad from its diff, and that does not hold for performance regressions, where the predicate is a noisy continuous measurement and a single commit's diff carries no signal about its effect on a 3% throughput change.

Smallest defensible result. A characterization of how badly bisection degrades when the predicate is a noisy performance measurement rather than a crash — measurement variance versus regression magnitude, and the number of repeated runs needed per bisect step to keep the traversal correct — then a bisect strategy allocating measurement budget adaptively instead of uniformly. Traces plus one workstation; no GPU.

How it goes wrong, and this is serious. Intel's LKP / 0-Day CI already performs automated kernel performance-regression bisection in production, with statistical repetition, and has for years. (Recalled rather than verified in this pass — verify before committing, because if it publishes its methodology anywhere your contribution evaporates.) Reviewer sentence: "this is statistical hypothesis testing under a noisy oracle, a solved problem in sequential analysis — where is the systems contribution?" Honest departmental read: Software Engineering with a performance-measurement veneer.

---

Area 6 — LLM-generated or LLM-checked kernel API-usage specifications

Rating: the best surviving option in this set. The one area where the incumbent literally documents the gap in its own reference manual.

The occupants are all adjacent rather than on top.

• Kernel API Specification Framework — Sasha Levin, RFC v4 (Aug 2025) through PATCH v3/v4 (Apr–May 2026). v4 RFC · v3 · v4. Machine-readable specs in kerneldoc with ELF-section storage, a debugfs interface, ftrace tracepoints, a Rust extraction tool, KUnit tests, and CONFIG_KAPI_RUNTIME_CHECKS for runtime validation. The spec vocabulary is exactly what you would want: contexts: accepting process, softirq, hardirq, nmi, atomic, sleepable, and lock: … type: accepting mutex, spinlock, rwlock, seqlock. After four-plus rounds over a year, the specified APIs are: sys_open, sys_close, sys_read, sys_write, sys_madvise, sys_sched_setattr, mlock, execveat. Eight functions. The series' own future-work list names "Contract Verification: static analysis to verify implementation matches specification."
• Compiler-Based Context Analysis — Linux kernel documentation, 7.0. docs. Clang capability analysis landed for lock-safety checking via __must_hold() and friends. The documentation states the limitation outright: "Clang's analysis explicitly does not infer context locks acquired or released by inline functions. It requires explicit annotations." It also notes that lockdep_assert_held() informs the static analysis — the bridge between the dynamic and static worlds you would exploit.
• KNighter — SOSP 2025, cited above. The closest competitor, and the distinction is sharp: KNighter synthesizes checkers (CSA rules learned from historical patch commits); it does not infer per-function contracts. It also documents the cost discipline you would inherit: bounded context windows, hundreds of dollars per full-kernel scan, hallucination on large systems.
• DSAC — hybrid flow analysis for sleep-in-atomic-context bugs. Non-LLM, pre-existing, and the baseline you must beat.
• Trap to avoid: searching "kernel contracts" returns Kernel Contracts: A Specification Language for ML Kernel Correctness Across Heterogeneous Silicon (arXiv 2604.22032) and its follow-ons — these are about GPU compute kernels, an entirely different meaning of the word. Do not cite them; do not let them make the area look crowded when it isn't.

Surviving gap — unusually well-formed: Clang's context analysis states it does not infer context locks and requires explicit annotations, and the Kernel API Specification Framework assumes maintainers will hand-write those annotations — an assumption that does not hold across 40 million lines of C, as evidenced by eight annotated functions after a year of upstream effort.

Smallest defensible result. Infer __must_hold / __acquires / context-class annotations for a bounded set of kernel functions with an LLM, and validate them against three independent ground-truth sources available for free: existing hand-written sparse/Clang annotations, lockdep runtime observations under a workload, and might_sleep() / might_fault() assertion sites. Report precision and recall separately for the "annotation is correct" and "annotation is complete" cases, and report cost per function. The result is a number nobody has: what fraction of the kernel's locking discipline is mechanically recoverable, and at what price per function.

Hardware: a kernel build machine, a QEMU/KVM setup with lockdep enabled, and API credits. Zero GPU. The cheapest-to-execute and highest-ceiling combination in the report.

How it goes wrong.

1. Your baseline is not "nothing," it is lockdep. Lockdep already finds locking-discipline violations at runtime, in production, for free, and has for twenty years. A reviewer will say: "lockdep already catches this dynamically; static annotation only helps for paths you never execute — quantify that residue or you have nothing." You must find and measure the not-executed residue, and it may be small.
2. Correlated errors. If the LLM infers the annotation and you use an LLM to adjudicate disagreements, the soundness argument collapses — the same seam that sank the Kgent option. Keep the oracle mechanical (lockdep, sparse, compiler) and never let the model grade itself.
3. Reviewer vocabulary for "already solved": "specification mining" and "invariant inference." This is Daikon (1999), and there is a twenty-five-year literature on mining API usage protocols and temporal specifications from code and traces. Run your idea-killing search against specification mining, API protocol inference and typestate inference before committing — that is where the prior art hides, and it will not surface under kernel-flavoured queries.
4. Levin is upstream, well-connected, and explicitly working on "the intersection of AI and kernel engineering" (he has proposed official guidelines for AI-assisted kernel contributions). The chance that he or a student points an LLM at his own framework within your thesis window is not small.

Reads as: genuinely contested, and this is the thing to discuss with your advisor first. Framed as "can we recover the kernel's synchronization discipline mechanically, and what does that tell us about how much of the kernel's locking contract is implicit?" it is an OS thesis about kernel structure. Framed as "LLM-based specification inference with precision/recall tables" it is a PL/SE thesis. Same experiments, different framing, and the framing decides your committee's reaction. Given the Kgent precedent, treat the drift risk as the primary threat rather than the crowdedness.

---

Area 7 — Evaluation-methodology and accounting audits

Rating: crowded as a genre; one unaudited subfield remains.

Bad news first: the "charge the learned system for its own cost" move is now a recognized genre with a template, executed independently in at least four subfields. That makes the framing easy to defend and the novelty hard to claim.

• Caching: 3L-Cache (FAST 2025) and S4-FIFO / Learning-Augmented Heuristics (OSDI 2026).
• Prefetching: T-LITE (ISCA 2024) — quantified Voyager's 988× latency and 10.8× storage infeasibility.
• Learned indexes, audited three times over: Understanding Robustness Issues of Updatable Learned Indexes — SIGMOD 2026, PDF (none of the SOTA updatable learned indexes robustly beats B+tree or ART; ALEX and LIPP space overhead up to 10× the indexed data; DyTIS insert performance off by nearly three orders of magnitude); How good are multi-dimensional learned indexes? — VLDB Journal 2024, DOI; Indexing meets machine learning: a systematic literature review — Journal of Big Data 2026, article, reporting that 67.3% of 49 studies used synthetic or benchmark-curated data, only 10 of 49 used SOSD, and most evaluated read-only workloads.
• In-kernel ML cost, partially audited: LAKE (ASPLOS 2023) already concluded accelerators are needed to absorb ML load and that benefit is subsystem/workload/hardware dependent. LearnedCache — arXiv 2605.26168v2, preprint — concedes its own decision overhead and that a cgroup allocation at 25% of database size is "wholly infeasible" for it. The substrate is cache_ext: Customizing the Page Cache with eBPF — SOSP 2025, DOI · PDF, pp. 462–478 (Zussman et al., Columbia + IBM; eight policies, up to 70% higher throughput and 58% lower tail latency; ~200 LOC in the page cache plus ~2,000 supporting). Also LWN on the LSFMM+BPF 2026 session.
• Observability tooling that would let you do the accounting: ProfInfer — MLSys 2026, PDF (eBPF LLM inference profiler, 0.1–3.67% overhead depending on library); eInfer — DOI.

Where the accounting has not been done: LLM-assisted kernel engineering. PortGPT reports 89.15% success and says nothing about cost per patch. LinuxFL+ says "minimal costs" without a dollar figure or a compute-equivalent non-LLM comparison. AUTOSEL reports nothing quantitative. KNighter is the only system in this entire report treating inference cost as first-class, and only operationally. Meanwhile the maintainer-facing cost — false positives per accepted suggestion — is the metric that determines whether any of this gets adopted, and nobody publishes it.

So: the caching subfield's accounting question is settled; the LLM-for-kernel-maintenance subfield reports success rates without reporting inference cost, human review cost, or comparison against a compute-normalized conventional baseline. This is the compute-normalized fuzzer re-evaluation topic generalized from fuzzing to maintenance — the same pleasing asymmetry, one field wider.

Also mandatory reading before committing to anything in this report: GenAI for Systems: Recurring Challenges and Design Principles from Software to Silicon — arXiv 2602.15241. Preprint, venue unconfirmed. Covers 275+ papers across eleven application areas and three layers of the stack, and distills open research questions. If your idea is in AI-for-systems, it is either in this survey or you need to explain why not. Use it as an idea-killer, not a citation.

How an audit thesis goes wrong. You must be willing to publish a critique, and you cannot match the field's statistical power. Reviewer vocabulary: "this is a reproducibility study, not a contribution," which 3L-Cache overcame by having 4,855 traces and you will not. Narrow the claim to accounting.

Reads as: depends on the subfield audited. Auditing in-kernel ML overhead reads as OS. Auditing LLM maintenance tooling reads as SE.

---

Area 8 — Other credible GPU-free 2026 gaps

Three observations rather than a fourth candidate.

OS knob tuning is closed. SemaTune/TuxBot (arXiv 2605.15026, preprint) tunes 41 Linux knobs with typed validation and apply/revert, +72.5% over defaults at ~$0.20 per session, and explicitly scopes itself out of fast-path controllers — "we do not study kernel fast-path controllers such as the CPU scheduler, a packet scheduler, or a TCP congestion controller." That exclusion is the useful thing in it: the fast path is where anything is left, which is also where the work is hardest. Database-side: AgentTune — SIGMOD 2026, PDF.

A cheap publication venue exists, and it changes the calculus. AgenticOS @ SOSP 2026 — site — is the 2nd workshop on OS design for AI agents, soliciting position papers and experience reports, with topics mapping onto the agent-lane candidates and "agents managing systems: kernel tuning, anomaly detection, failure recovery." The first edition's deadline was 8 Feb 2026, so the next round is the target. A workshop position paper is a realistic month-9 milestone and a way to plant a flag before being scooped — the mitigation guide/01-scoping.md already recommends.

Nothing else surfaced that beats area 6 or the existing Tier 1. The 2026 AI-for-systems frontier that isn't GPU-bound has converged on agents-as-a-workload and LLM-for-kernel-engineering. The learned-policy-replaces-heuristic lane, which is what "AI for Systems" meant in 2020–2023, is substantially picked over: LAKE surveyed five subsystems in 2023, Heimdall industrialized the block layer in 2025, KML did storage in 2023, and S4-FIFO defeated the whole premise in caching in 2026.

---

Summary table

Recommendation

Area 6 is the strongest thing here, and it beats several existing Tier 1 entries on cost and on how cleanly the gap is stated — an incumbent that documents its own inability to infer, an upstream framework stalled at eight annotated functions, and three free mechanical ground-truth sources. Run the specification-mining idea-killing search first, and settle the framing question with your advisor before writing a proposal, because that is what decides whether it is an OS thesis.

Area 1f (khugepaged collapse creep) is the best pure-OS option, cheap and cleanly in the department, with a real stated limitation to attack — but a smaller ceiling, and the evidence it is open is only absence of hits.

Areas 2 and 1d should be dropped outright. Kconfig debloating has been pre-refuted by ACSAC 2025's structural-ceiling finding; learned congestion control has five occupants including the exact selection framing at NSDI 2025, and it isn't an OS topic anyway.

Areas 3, 4 and 5 have the most exploitable gaps and the worst departmental fit. If your advisor sits across OS and SE, area 3 is the cheapest publishable result in this entire report — the ground truth is free, the metric is unpublished, and the pain is documented on LWN. If they don't, it will cost you your first committee meeting.

One consistency note: the prior finding that every estimate moved toward "more crowded" held again. Six of eight areas landed at crowded or active-with-production-occupancy, and the two open ratings rest on absence of hits. Treat 1f and 1g as lower bounds on crowdedness, not as findings.