{"id":2540,"date":"2022-02-11T12:46:00","date_gmt":"2022-02-11T11:46:00","guid":{"rendered":"https:\/\/i4wpdev.cs.fau.de\/?page_id=2540"},"modified":"2026-02-03T10:26:38","modified_gmt":"2026-02-03T09:26:38","slug":"pave","status":"publish","type":"page","link":"https:\/\/i4wpdev.cs.fau.de\/en\/research\/pave","title":{"rendered":"PAVE"},"content":{"rendered":"

Power-fail aware byte-addressable virtual non-volatile memory<\/h3>

(Third Party Funds Group – Sub project)<\/p>

Overall project: <\/strong>SPP 2377: Disruptive Memory Technologies
Project leader: <\/strong>Wolfgang Schr\u00f6der-Preikschat<\/a><\/span>, Dustin Tien Nguyen<\/span>
Start date: <\/strong>5. April 2021
End date: <\/strong>14. May 2026
Acronym: <\/strong>PAVE
Funding source: <\/strong>DFG \/ Schwerpunktprogramm (SPP)
URL: <\/strong>https:\/\/sys.cs.fau.de\/en\/research\/pave-note<\/a><\/p>

Abstract: <\/h4>

Virtual memory (VM) subsystems blur the distinction between storage and memory such that both volatile and non-volatile data can be accessed transparently via CPU instructions. Each and every VM subsystem tries hard to keep highly contended data in fast volatile main memory to mitigate the high access latency of secondary storage, irrespective of whether the data is considered to be volatile or not. The recent advent of byte-addressable NVRAM does not change this scheme in principle, because the current technology can neither replace DRAM as fast main memory due to its significantly higher access latencies, nor secondary storage due to its significantly higher price and lower capacity. Thus, ideally, VM subsystems should be NVRAM-aware and be extended in such a way that all available byte-addressable memory technologies can be employed to their respective advantages. By means of an abstraction anchored in the VM management in the operating system, legacy software should then be able to benefit unchanged and efficiently from byte- addressable non-volatile main memory. Due to the fact that most VM subsystems are complex, highly-tuned software systems, which have evolved over decades of development, we follow a minimally invasive approach to integrate NVRAM-awareness into an existing VM subsystem instead of developing an entirely new system from scratch. NVRAM will serve as an immediate DRAM substitute in case of main memory shortage and inherently support processes with large working sets. However, due to the high access latencies of NVRAM, non-volatile data also needs to be kept at least temporarily in fast volatile main memory and the volatile CPU caches, anyway. Our new VM subsystem - we want to adapt FreeBSD accordingly - then takes care of migration of pages between DRAM and NVRAM, if the available resources allow. Thus, the DRAM is effectively managed as a large software-controlled volatile page cache for NVRAM. Consequently, this raises the question of data losses caused by power outages. The VM subsystem therefore needs to keep its own metadata in a consistent and recoverable state and modified pages in volatile memory need to be copied to NVRAM to avoid losses. The former requires an extremely efficient transactional mechanism for modifying of complex, highly contended VM metadata, while the latter must cope with potentially large amounts of modified pages with limited energy reserves.<\/p><\/p>

Publications: <\/h4>