Reevaluating the Linux Page Cache Design in the Presence of High-Bandwidth and Low-Latency Flash Storage
- Typ der Arbeit: Bachelor-/Masterarbeit
- Status der Arbeit: laufend
- Projekte: ParPerOS
- Betreuer: Kenny Albes, Daniel Lohmann
- Bearbeiter: Paul Behrendt
[Generated with AI]
Context
For a long time Linux followed the philosophy that only used memory is good memory. Typically, most of the unused system memory is used to cache contents of files upon first access. This system is called the Page Cache1. While having the potential to decrease the access latency on successive file operations, it also leads to a large memory footprint and increases physical memory fragmentation over time. Especially in a virtualized cloud environment this might be problematic as VMs will drastically increase their memory consumption over their lifetime. Destructive approaches, such as ballooning are used to manually shrink the page cache at a certain interval. However, another solution is to constructively decrease the page cache size by being more selective about what to cache. Now that high speed SSD with >14 GB/s bandwidth are commonplace, blindly caching everything will likely yield diminishing returns compared to its disadvantages.
Problem
Linux's page cache design suffers from major drawbacks. Its general design decisions stem from a time when hard drives were exceptionally slow and suffered heavy performance penalties upon random access. This does not hold true for modern flash storage. Furthermore, Linux does not distinguish between workloads and generally assumes that each file is read more than once and potentially shared between multiple processes. Finally, the fundamental assumption that free memory can be used at zero cost does not hold true any longer. New cost models must weigh the costs of using that memory against the potential performance gain.
Goal
The goal of this thesis is to reevaluate these design decisions on a system with high-bandwidth flash storage and – depending on the scope – develop and implement page cache improvements based on the insights gathered.
For Bachelor and Master Thesis
To establish a baseline, the costs of reading and writing files (file-system lookup, actual read, page-cache population) need to be benchmarked. Expanding on that the impact of cache misses on a modern system for different workloads (compilation, web server, database, …) needs to be analyzed. Aside from the performance impact the anatomy of the page cache must be understood. Important metrics might include hit rates (read/written more than once) and share count of contents (ideally with respect to file type).
For Master Thesis (or 2. Bachelor Thesis)
Based on the observations gathered suitable design changes may be implemented. These include but are not limited to:
- Exposing the page cache directly to the SSD via a shared mapping eliminating any bounce buffers
- Cache only file system metadata and load everything else from disk
- Asymmetric approaches i.e., read from disk but cache/batch writes since theses are slower
- Never share page cache contents (or only specific file types) between processes allowing direct writes without
- Explore a granularity other than 4 KiB (page size)
Schedule
- Getting started: Familiarize with the Linux kernel, set up a suitable development environment, and establish a functional test setup.
- Measure a first baseline: As a first test the page cache should be disabled and the impact evaluated (using different workloads).
- Gather performance metrics: Analyze were the time is spent during I/O.
- Understand the page cache contents: Gather information about how contents are typically used (w.r.t. workload).
Topics: C, NVMe, Linux kernel
References