Masters portal

Topic selectiontopic-selection/reports/learned-caching-and-fuzzing

Report: Learned Caching and Kernel Fuzzing

Produced 26 August 2026 by a literature-check agent instructed toward skeptical calibration rather than encouragement, and required to verify every citation in search results rather than recall it. Reproduced verbatim, including its note on sources it excluded as uncitable.

Topics checked: learned cache replacement / prefetching net of overhead; LLM-guided kernel fuzzing and crash triage.

TOPIC A: Learned cache replacement / prefetching net of overhead

1. CROWDEDNESS: 3. The exact "charge learning for its own CPU cost" framing is the explicit thesis of a FAST '25 paper and was then used to defeat learned caches at OSDI '26 — the critique is not just published, it has already been resolved against learned policies.

2. STRONGEST / MOST RECENT

  • 3L-Cache: Low Overhead and Precise Learning based Eviction Policy for Caches, FAST '25 — PDF. Compares 12 policies (6 heuristic; LeCaR, CACHEUS, GL-Cache, LRB, HALP) on 4,855 traces reporting CPU overhead relative to LRU; finds LRB costs up to 172× LRU.
  • Learning-Augmented Heuristics (S4-FIFO), OSDI '26 — USENIX. Keeps ML off the data path; beats 3L-Cache by 8% at heuristic-level throughput, and shows 3L-Cache degrades FIFO by 8.8% on its worst trace.
  • SIEVE is Simpler than LRU, NSDI '24 — PDF. 1,559 traces; a non-learned policy matches or beats learned ones.
  • A New Formulation of Neural Data Prefetching (Twilight/T-LITE), ISCA '24 — PDF. Quantifies Voyager's infeasibility: 988× latency and 10.8× storage reductions needed.
  • GL-Cache, FAST '23 — PDF. Establishes overhead amortization as the design axis.

3. IS THE MVP DONE? Yes. Zhou et al. (3L-Cache, FAST '25) did the uniform overhead accounting; Xia et al. (OSDI '26) added throughput parity and worst-case robustness.

4. SURVIVING GAP. Narrow: does any learned eviction advantage survive inside the Linux page cache, where the data path is nanoseconds, not a CDN control plane? Only one preliminary, unrefereed preprint exists (LearnedCache, arXiv 2605.26168, FIFO baseline only). Replicating LeCaR/LRB/3L-Cache under cache_ext/eBPF with charged overhead is unclaimed — but it is a kernel-engineering thesis, not a measurement thesis.

5. RESOURCE BAR. Low: trace replay on one large-memory machine. Traces are public (libCacheSim, CMU PDL). Not the constraint; novelty is.

Excluded as unciteable: an MDPI "comprehensive analysis" (weak venue, no released artifact) and a personal-site "MMU Handbook" chapter that miscites LeCaR as NSDI '19.

TOPIC B: LLM-guided kernel fuzzing and crash triage

1. CROWDEDNESS: 3. At least six distinct groups published LLM-driven kernel fuzzers in 18 months, syzkaller maintainers are upstreaming this work, and crash triage is separately occupied — both halves of the proposed MVP are taken.

2. STRONGEST / MOST RECENT

  • KernelGPT, ASPLOS '25 — PDF. LLM-synthesized syzlang specs; 24 bugs, 11 CVEs, specs merged upstream. The baseline you'd have to beat.
  • SyzGPT: Unlocking Low Frequency Syscalls with Dependency-Based RAG, ISSTA '25 — DOI. Exactly the "reach code the grammar rarely does" framing: +17.7% coverage, +58% low-frequency-syscall coverage vs seven fuzzers.
  • KnitFuzz, CODASPY '26 — PDF. LLM-generated C seeds for stateful socket syscalls; +19.4% blocks over syzkaller/Healer/Moonshine.
  • Patch-to-PoC / K-REPRO, arXiv 2602.07287 — PDF. LLM agents reproduce >50% of 100 KernelCTF bugs, beating SyzDirect.
  • GPTrace: Crash Deduplication Using LLM Embeddings, ACM '25 — DOI. LLM-embedding + HDBSCAN dedup on 300k crashing inputs. Plus ECHO (Electronics '25) for kernel-specific stack dedup.

3. IS THE MVP DONE? Yes, both halves, by different groups. Coverage-delta-vs-syzkaller: KernelGPT, SyzGPT, KnitFuzz, SyzAgent. Crash clustering: GPTrace, ECHO, dedupT.

4. SURVIVING GAP. One, and it is methodological, not constructive: do reported LLM-fuzzer coverage gains survive when the LLM's own compute is converted to CPU-hours and given to plain syzkaller instead? No paper above does this; KernelGPT charges only 192 CPU-hours of fuzzing and nothing for inference. This is the Topic-A accounting trick applied to Topic B, where it is still unpublished. It is a real 9–12 month thesis — but it is a critique paper, and you must accept that outcome.

5. HARDWARE BAR. Published norms: KernelGPT ran 24-hour campaigns at 192 CPU-hours each, ×3 repetitions ×3 configurations. KnitFuzz used 16 CPUs/instance, 24-hour campaigns averaged over ten runs across four fuzzers on a 475 GB-RAM host — on the order of 10⁴ CPU-hours. SyzGPT's own README demands 16+ cores and 64 GB minimum. A student with one 16-core KVM box can run one fuzzer arm at published rigor, not four with ten repetitions each; you cannot match the field's statistical power, which is precisely why an accounting study (fewer arms, sharper claim) is the only defensible framing left.