arXiv ScienceSearch

arXiv · 2605.26168

LearnedCache: eBPF-Integrated Perceptron-Based Eviction Policies for the Linux Page Cache

Abstract

Any device that runs Linux uses the Linux page cache, a central pillar in OS and application performance, serving to reduce extraneous disk access. Many page cache eviction policies have been developed but remain bound by the rigidity of heuristics. Promising research has been done on neural cache eviction policies, but only in the field of user-space applications such as CDNs. We present LearnedCache, a set of machine-learning-based page cache eviction policies that run live inside the Linux kernel through the cache_ext eBPF framework. LearnedCache trains a lightweight perceptron per workload on kernel trace data collected using eBPF to predict whether eviction candidates will be reused within a bounded horizon and deploys it through two eBPF policies. The resulting policies consistently compete with and outperform both external heuristic policies and the kernel's own, improving application throughput by up to 44% versus standard kernel policies.

Explore related subjects

Keep this discovery

Explore connections, maps & timelines

BibTeXRIS

Zejia Qi. 2026-07-30. LearnedCache: eBPF-Integrated Perceptron-Based Eviction Policies for the Linux Page Cache. https://arxiv.org/abs/2605.26168

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related papers

Violet: Enabling Full Virtualization for M-mode RTOS on RISC-V

In embedded systems, complex configurations may be required, such as the simultaneous execution of a real-time operating system (RTOS) and a general-purpose operating system (GPOS), or the operation of multiple RTOS instances. Embedded system hypervisors have been studied and developed to meet these requirements for architectures like ARM and x86. RISC-V is experiencing growing adoption in embedded systems and faces similar needs. However, RISC-V's virtualization support targets only U-mode (where applications run) and S-mode (where general-purpose OSs run) as virtualization levels. The M-mode, where RTOSs like FreeRTOS or Zephyr run, is excluded from virtualization. This means that, similar to architectures like ARM, running an RTOS on a Virtual Machine (VM) using methods based on virtualization support features is impossible. Therefore, this paper proposes the Violet hypervisor. Violet combines RISC-V's virtualization features with software-based emulation, enabling the execution of unmodified M-mode RTOSs. Evaluation verified the validity of the M-mode emulation functionality using RISC-V architecture tests. Furthermore, this was implemented on the SiFive HiFive Premier P550 hardware, demonstrating that existing RTOSs can run on Violet's VM and that coexistence with GPOSs like Linux is also possible. The performance evaluation also quantified the overhead introduced by M-mode emulation on M-mode CSR accesses, timer interrupt latency, and context switching.

cs.OS

Continuum: Efficient and Robust Multi-Turn LLM Agent Scheduling with KV Cache Time-to-Live

KV cache management is essential for efficient LLM inference. To maximize utilization, existing inference engines evict finished requests' KV cache if new requests are waiting. This policy breaks for agentic workloads, which interleave LLM calls with tools, introducing pauses that prevent effective KV reuse across turns. Since many tool calls have much shorter durations than human response multi-turn chatbot, it would be promising to retain the KV cache in during these tools. However, many challenges remain. First, we need to consider both the potential cost of recomputation or reloading (if offloading enabled) as well as the increasing queueing delays after eviction from GPU. Second, due to the internal variance of tool call durations, the method needs to remain robust under limited predictability of tool call durations. We present Continnum, a serving system to optimize job completion time for multi-turn agent workloads by introducing time-to-live mechanism for KV cache retention. For requests that generate tool calls, Continnum selectively pins the KV cache in GPU memory with a time-to-live value determined by the reload cost and potential queueing delay induced by eviction. When the TTL expires, the KV cache can be automatically evicted to free up GPU memory, providing robust performance under edge cases. When combined with program-level first-come-first-serve, Continnum preserves multi-turn continuity, and reduces delay for agentic workflows. Evaluations on real-world agents (SWE-Bench, BFCL, OpenHand) with Llama-3.1 8B/70B, Gemma-3 12B, and GLM-4.5 355B shows that Continnum improves the average job completion times by over 8x while improving throughput.

cs.OS

MARS: Multi-stage Accelerated Read Stack for Large-buffer Buffered Reads

Large-buffer reads increasingly connect data-intensive applications to high-speed storage. They amortize system-call overhead and create a larger in-kernel window for organizing page-cache work and submitting I/O. However, Linux buffered read primarily exploits only the former benefit. Within a large read, its conventional interleaved path repeatedly switches among fine-grained page-cache operations, amplifying metadata and serial orchestration overheads and failing to consistently expose enough in-flight requests to modern parallel SSDs. We present MARS, a multi-stage accelerated read stack for synchronous large-buffer buffered reads. MARS treats each large-range read as one unit of work and stages page-cache operations by data structure and dependency. During I/O waits, it handles user-buffer page faults and performs reorderable data copies early. Opportunistic kernel workers then copy remaining data in parallel and, when the backend provides sufficient parallelism, optionally submit I/O in parallel. We implement MARS in Linux 6.6.58. For MiB-scale fio reads, MARS improves bandwidth by up to 6.56 times over Linux. On five NVMe SSDs in RAID0, it reaches 36.87 GiB/s for 128 MiB random reads, 4.44 times Linux. MARS also accelerates DuckDB/Parquet queries by 1.80--2.15 times and ExecuTorch model loading by 3.17--3.61 times.

cs.OS