Stop Chasing AI-for-Kernel Papers: The Real Opportunity Is Kernel-for-AI

A veteran Linux kernel engineer reflects on the widening gap between AI academic research and kernel engineering practice.

Kernel Work Remains Abundant Regardless of AI

Even without AI, the kernel has endless unsolved problems:

Scheduler: power-performance balance, scheduling latency causing UI jank, priority inversion, user-space lock priority inversion.

Memory management: allocation latency, reclaim latency and overhead, fragmentation, LRU reclaim precision (reducing refaults), large folios stability, readahead hit-rate improvement (file and swap-in), swap-out/swap-in performance.

Filesystem performance, mixed storage media coordination, large folios filesystem support.

With memory and storage costs rising, kernel engineers still have vast optimization opportunities.

The Flood of "AI-for-Kernel" Papers

Academia produces many papers on using AI to optimize the kernel: AI-written schedulers, I/O algorithms, system parameter tuning. The author notes academia must publish to sustain its evaluation system, but kernel engineers should not blindly chase every paper.

Why Most Papers Never Reach Mainline

Paper authors are rarely long-term, deep participants in the kernel community.

The kernel community evolves conservatively, prioritizing engineering stability over benchmark gains on specific workloads.

The author estimates 99% of such papers never become part of mainline.

Case Study: KML Paper (2021)

The paper https://arxiv.org/abs/2111.11554 (KML: Using Machine Learning to Improve Storage Systems) proposed a kernel-space ML framework for I/O readahead and NFS rsize tuning. Five years later it remains a paper, not a mainline feature. Mainline acceptance requires:

Long-term patch review

Subsystem maintainer acceptance

Community consensus on performance, security, and maintainability

Community questions include: why not optimize existing heuristic readahead instead of introducing ML? What is the real benefit, overhead, generality, and maintainability?

Engineering Intuition: Code Lifespan Tied to Mainline Potential

Kernel engineers need intuition about what can enter mainline. Code lifespan is proportional to its probability of mainline acceptance. Out-of-tree maintenance costs kill projects that cannot merge; future mainline alternatives will also replace them.

"AI for Kernel" Is Not Wrong, But Requires Community Investment

AI-adaptive parameter tuning and reinforcement learning for readahead/swap-in accuracy show promise, but need strong, sustained community effort to mature.

The Real Opportunity: "Kernel for AI"

More urgent and fruitful is adapting the kernel for AI workloads:

CPU/GPU/NPU scheduling coordination

Reducing memory footprint and copies under LLM loads

Accelerating I/O loading paths

Kernel engineers should collaborate end-to-end with AI framework and application engineers (e.g., Doubao agents, Google Gemini, phone vendor assistants). In the AI pipeline, coordinating diverse hardware (camera, screen, GPU, NPU, DMA engines), optimizing memory bandwidth, zero-copy, and storage I/O can deliver both speed and power efficiency.

Three-Point Summary

Ignore AI: kernel still has infinite work; keep mastering fundamentals.

With AI: "kernel for AI" creates bold new opportunities.

"AI for kernel" has opportunities, but stay calm and evaluate carefully before diving in.