# Crazy: Unifying Memory and CPU Management Subsystems

Alain Tchana, Jordan Gounou, Papa Assane Fall, Renaud Lachaize, Hippolyte Tapamo, Celestin Parfait Bessala Bessala, Vivien Quema

<figure><img src="image_1.png" /></figure>

## To cite this version:

Alain Tchana, Jordan Gounou, Papa Assane Fall, Renaud Lachaize, Hippolyte Tapamo, et al.. Crazy: Unifying Memory and CPU Management Subsystems. APSys '25: 16th ACM SIGOPS Asia-Pacific Workshop on Systems, Oct 2025, Seoul (Korea), South Korea. pp.1-7, 10.1145/3725783.3764398. hal-05474726

HAL Id: hal-05474726

https://hal.science/hal-05474726v1

Submitted on 23 Jan 2026

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# CRAZY: Unifying Memory & CPU Management Subsystems

**Alain Tchana***

Univ. Grenoble Alpes, CNRS,
INRIA, Grenoble INP, LIG, 38000
Grenoble, France

**Jordan Gounou**

Univ. Grenoble Alpes, CNRS,
INRIA, Grenoble INP, LIG, 38000
Grenoble, France

**Papa Assane Fall**

Univ. Grenoble Alpes, CNRS,
INRIA, Grenoble INP, LIG, 38000
Grenoble, France

**Renaud Lachaize**

Univ. Grenoble Alpes, CNRS,
INRIA, Grenoble INP, LIG, 38000
Grenoble, France

**Hippolyte Tapamo**

University of Yaoundé I, LAMOCA,
Ngoa Ekelle, BP 812 Yaoundé,
Cameroun

**Celestin Bessala Bessala**

University of Yaoundé I, BetaLab,
Ngoa Ekelle, BP 812 Yaoundé,
Cameroun

**Vivien Quema**

Univ. Grenoble Alpes, CNRS,
INRIA, Grenoble INP, LIG, 38000
Grenoble, France

## Abstract

Memory management (MM) and scheduling are two core components of the operating system (OS) that are traditionally studied and implemented separately, resulting in doubled development and maintenance efforts for kernel developers. In this work, we identify the conceptual similarities between these two subsystems and propose their unification under a generalized resource mapping framework called CRAZY.

To validate this approach, we developed a prototype, CRAZYOS, by merging two semi-microkernels for MM and CPU management. We then implemented several policies atop CRAZYOS, including the sophisticated Completely Fair Scheduler (CFS).

**CCS Concepts: Software and its engineering → Operating systems; Security and privacy → Operating systems security.**

**Keywords:** Operating Systems, Memory Management, Scheduling

**ACM Reference Format:**

Alain Tchana, Jordan Gounou, Papa Assane Fall, Renaud Lachaize, Hippolyte Tapamo, Celestin Bessala Bessala, and Vivien Quema. 2025. CRAZY: Unifying Memory & CPU Management Subsystems. In *16th ACM SIGOPS Asia-Pacific Workshop on Systems (APSys '25), October 12–13, 2025, Seoul, Republic of Korea*. ACM,

New York, NY, USA, 7 pages. https://doi.org/10.1145/3725783.3764398

## 1 Introduction

CPU management (scheduling) and physical memory management (MM) are two core missions of an operating system (OS). Since the inception of the field, these two concerns have been studied separately, both from a theoretical and a practical point of view: (1) they rely on different types of algorithms and formalisms and, (2) they are typically organized as distinct subsystems [6, 11] within an OS codebase, with orthogonal building blocks (mechanisms, policies) and almost no code sharing (see Figure 1, discussed in §2).

In the present paper, we revisit and question this state of affairs: upon closer examination, it becomes clear that these two OS components (scheduler and MM) have many similarities in their principles, which can be conceptualized as a common *mapping problem*, where virtual resources are mapped onto physical resources. We propose an approach, dubbed CRAZY, to explore the ramifications of this potential duality. By unifying MM and scheduling subsystems, CRAZY aims to streamline operations, improve maintainability, and enable a cohesive approach to resource management.

First, (§3) we investigate the conceptual similarities between scheduling and MM; we show that their isomorphism is not just a shallow impression and explore a generalization of those two concepts under a more general and common resource mapping problem. For the CPU, the physical resources are logical cores (lCores), while the virtual resources are kernel-level threads (kThreads). For memory, the physical resources are physical pages (pPages), and the virtual resources are virtual pages (vPages).

<footnote>*Corresponding author: alain.tchana@grenoble-inp.fr</footnote>
Then, (§4) we implement this generalization into a common interface to prove our vision. To demonstrate the practicality of CRAZY (§5), we build CRAZYOS, a Linux-based prototype using a microkernel approach, which is known for simplifying the architecture of the OS. More precisely, we leverage modified versions of ghOSt [15] and USM, which are respectively a scheduler and an MM component running in user space, and (§6) we use CRAZYOS to implement several policies, ranging from simple ones (Random, Round Robin, and FIFO) to more complex ones such as the Completely Fair Scheduler [3] (CFS); each of these policies can be used by the scheduler, the MM, or both.

<figure><img src="image_3.png" /><figcaption>**Figure 1.** Linux subsystem architecture.</figcaption></figure>

## 2 Traditional OSes

To better understand CRAZY, we first examine how current OSes architect their subsystems. Figure 1 illustrates this organization specifically for the CPU and MM subsystems, using Linux for illustration. Each subsystem comprises three main components: *internals*, *interrupt handlers* and a public *interface* (dashed rectangles in Figure 1).

*Internals* are the core implementation details of a subsystem, encompassing logic such as CPU (*Internals* CPU in Figure 1) and MM (*Internals* Mem in Figure 1) operations. These details remain encapsulated within the subsystem, ensuring modularity and preventing external exposure.

*Interrupt handlers* are responsible for managing events generated by the devices overseen by the subsystem. Each subsystem features its own specific handlers, which activate the corresponding logic within the internals of their respective subsystems. For instance `do_fault()` handles several memory-related events in Linux.

The *interface* serves as the primary mechanism for interactions within the subsystem itself, as well as between the subsystem and other subsystems or user-space applications. Interfaces are categorized into two types: *APIs* and *function pointers* (FP — FP CPU and FP Mem in Figure 1). *APIs* are complete functions provided by core OS

developers to factorize code usage and promote consistency. *FPs* (e.g., `yield_task()`) are function signatures that must be implemented by developers specializing a subsystem. *FPs* are invoked by the OS core without needing knowledge of their specific implementations.

Furthermore, *APIs* can be divided into two categories: *Orchestrator functions* (OCF — OCF CPU and OCF Mem in Figure 1) and *low-level functions* (LLF — LLF CPU and LLF Mem in Figure 1). An OCF (e.g., `schedule()`) orchestrates calls to multiple interface functions (*FPs* or *APIs*). It typically invokes at least two interface functions. *LLF* (e.g., `pick_next_task()`) are simpler and restricted to calling at most one function from the interface.

Following this architecture, Linux developers implement and maintain the CPU and memory management subsystems separately, increasing the codebase and doubling the maintenance efforts, despite the potential for effort mutualization as we show in the next section.

## 3 Isomorphism Between CPU Scheduling and Memory Management

This section highlights the similarities between CPU and memory management, which motivate CRAZY, a unified subsystem for managing these two types of resources (presented in §4). We emphasize the isomorphism between these resources across various dimensions, such as resource state, grouping, protection, affinity, and more. Our analysis considers both physical, virtual resources and management goals to uncover these parallels.

<table><caption>**Table 1.** Physical Resource (pPages and lCores) Isomorphism.</caption><thead><tr><th>Dimensions</th><th>pPage</th><th>lCore</th></tr></thead><tbody><tr><td rowspan="3">State</td><td>Free</td><td>Available</td></tr><tr><td>Allocated</td><td>Assigned</td></tr><tr><td>Self Refresh</td><td>Sleep</td></tr><tr><td>Grouping</td><td>NUMA node</td><td>CPU package</td></tr><tr><td>Protection</td><td>MMU, Enclaves</td><td>Rings levels</td></tr><tr><td>Performance</td><td>RAM, Cache</td><td>Big/Little</td></tr></tbody></table>

### 3.1 Physical Resources Isomorphism

The similarities between pPages and lCores are summarized in Table 1.

**State.** The states of pPages and lCores share some similarities. (S1) Both can be allocated to a virtual resource. A pPage can be mapped in a process's page table to a vPage, and an lCore core can execute a kThread. (S2) Both can be reclaimed and detached from a virtual resource. A pPage can be unmapped from any page table and thus become again free for use. Similarly, an lCore
<figure><img src="image_4.png" /><figcaption>(a) ICore state-transition diagram.</figcaption></figure>

<figure><img src="image_5.png" /><figcaption>(b) pPage A state-transition diagram.</figcaption></figure>

<caption>**Figure 2.** Comparison of ICore and pPage state-transition diagrams.</caption>

can be idle and available to execute any `kThread`. (S3) Both can also be put to sleep to reduce their power consumption, thanks to the `ACPI` specification [1]. An `ICore` supports `cstates`. Similarly, `DRAM` modules can enter `self-refresh` mode to lower their power consumption while retaining their data. Notice that `cstates` provide far more granularity (different levels, C0-C5) compared to the basic on-off state of a `DRAM` module. Additionally, `cstates` can operate at a finer scale (ICores), whereas the `DRAM` module scale involves hundreds of `pPages`. It is conceivable that, over time, the granularity of energy control for `DRAM` modules could also be reduced. What we aim to highlight in (S3) is that the concept of a sleep state exists in both types of resources, which is sufficient to support our demonstration.

**State-transition diagram.** Figure 2 illustrates the state-transition diagram for each resource type. It clearly demonstrates that the similarities extend to this level as well. For instance, the `schedule` function (for Icores) in Figure 2a is analogous to the `map` function (for pPages) in Figure 2b, as both associate a virtual resource with a physical one. Similarly, the `deschedule` (for Icores) and `unmap` (for pPages) functions both detach the virtual resource from the physical one.

**Content.** Both resources have an internal state that must be initialized or restored when they are associated with virtual resources. For an `ICore`, this internal state corresponds to its registers, which are loaded by the OS when a `kThread` is scheduled on it. This content is either saved or discarded when the `kThread` is scheduled out or terminated, respectively.

For a `pPage`, the internal state corresponds to the memory words it contains. Their content is initialized (either from a file or to zero) when the `pPage` is allocated to a `vPage` (backed or anonymous). The content of a `pPage` is either saved or discarded when the `pPage` needs to be freed.

**Grouping.** `pPages` and `ICores` can both be grouped into larger physical resources. A `NUMA` memory node [13] can be considered as a collection of `pPages` grouped together as a single memory unit, while a `CPU` package represents a collection of cores, which, in turn, consists of multiple `ICores`.

**Protection.** Both `ICores` and `pPages` can be secured against unauthorized access or misuse. For `pPages`, Intel Software Guard Extensions [14] (`SGX`), for instance, restrict access to certain `pPages`, allowing only privileged programs to access them. For `ICores`, execution privilege levels (e.g., rings 0–3 and `VMX ROOT/NON-ROOT` modes on Intel machines) impose restrictions on the execution of certain instructions.

**Performance Levels.** `pPages` and `ICores` typically exhibit different performance levels. CPUs can adopt a Big.LITTLE architecture [2], featuring `ICores` with varying frequencies. Similarly, memory can also include portions of `DRAM`, `NVRAM` [22], or even `CXL` [23], each with distinct performance characteristics (e.g., latency, persistence, cache coherence, etc).

<table><caption>**Table 2.** Virtual Resources Isomorphism.</caption><thead><tr><th></th><th>vPage</th><th>kThread</th></tr></thead><tbody><tr><th rowspan="3">State</th><td>Invalid</td><td>Blocked</td></tr><tr><td>Valid</td><td>Runnable</td></tr><tr><td>Mapped</td><td>Running</td></tr><tr><th>Affinity</th><td>NUMA affinity</td><td>ICore affinity</td></tr><tr><th>Grouping</th><td>VMA</td><td>Process (cgroup)</td></tr><tr><th>Priority</th><td>mLock</td><td>Niceness</td></tr><tr><th>Authorization</th><td>R/W/X flags</td><td>seccomp, signal ignore</td></tr></tbody></table>

## 3.2 Virtual Resources Isomorphism

Just like their physical counterparts, virtual resources (kThreads and `vPages`) share many similarities, summarized in Table 2.

**State.** `vPages` and `kThreads` can be in the `Invalid` or `Blocked` states, respectively. A `vPage` is considered `Invalid` when it is not part of a virtual memory area [5] (`VMA`) and, therefore, cannot be mapped to a `pPage`. Similarly, a `Blocked` `kThread` is not ready for execution and thus cannot be scheduled on an `ICore`.

The opposite states are `Valid` and `Runnable`, respectively, for `vPages` and `kThreads`. A `vPage` is `Valid` when it belongs to a `VMA` but is not yet mapped to a `pPage` (either not allocated yet or resides in swap space). A
<figure><img src="image_6.png" /><figcaption>**Figure 3.** Comparison of kThread and vPage state-transition diagrams.</figcaption></figure>

Runnable `kThread` is ready for execution and is waiting to be scheduled on an `lCore`.

A `vPage` can transition to a `Mapped` state when it is placed in RAM. This state is analogous to the `Running` state for `kThreads`, indicating that the `kThread` is currently executing on an `lCore`.

**State-transition diagram.** As shown in the automata-tons in Figure 3, the state-transition diagrams of `vPages` and `kThreads` exhibit remarkable similarities. The `schedule` function, called by the OS’s scheduler, as-sociates a `kThread` with an `lCore`, while the `allocate_page` function, called by the OS’s memory manager (MM), as-signs a `pPage` to a `vPage`. Similarly, the `preempt` function (for `kThreads`) and the `swap-out` function (for `vPages`) represent decisions made by the scheduler and the MM, respectively, to remove a `kThread` from an `lCore` or a `vPage` from a `pPage`.

The `block` and `wake_up` functions are not decisions of the scheduler but rather notifications from the hardware or kernel about a `kThread`'s activity, particularly during I/O operations. Similarly, `mmap` [8] and `munmap` [9] are informational calls for the MM, indicating that specific `vPages` have been created or removed.

The `yield` function differs slightly, as it originates from the `kThread` itself, voluntarily deciding to be descheduled, whereas memory lacks the capability to initiate such actions autonomously.

**Grouping.** Both `vPages` and `kThreads` are grouped in bigger collections: A range of `vPages` are grouped in a VMA, which is itself a part of a Virtual Memory Address Space. Threads are part of a process which can itself be part of a container (cgroup [4], namespace [10], file system root, `seccomp` [12], etc.).

**Affinity.** Both `vPages` and `kThreads` have the concept of hardware affinities. A `vPage` could prefer to stay mapped to a `pPage` in some NUMA node. A `kThread` often prefers to be scheduled in the same `lCore` — or at least physical core — to minimize thread migrations.

**Priority.** The OS provides programs with the ability to give hints for both MM and scheduling policies. A `vPage` can be deemed essential, and the use of `mLock` [7] to prevent the MM from moving it to swap serves as

a hint to indicate its priority. Similarly, a user can define priorities for `kThreads` using the `nice` command. The priority of a `kThread` helps the scheduler determine which task to remove from the cores and which one to keep running. This priority value is a more flexible indicator compared to the binary nature of the `mLock` instruction. Introducing a more granular priority mechanism for MM, similar to the one used for scheduling, could be a valuable enhancement.

**Protection.** `vPages` and `kThreads` have authorization levels. A `vPage` can be restricted with R/W/X flags to inform the OS of the protection the page possesses. The `seccomp` [12] subsystem restricts the `kThread` by informing the kernel of the set of operations (syscalls) it is authorized to use.

### 3.3 Management Goal Isomorphism

We can also draw a parallel between CPU and memory management regarding their goal of minimizing resource waste. For example, the chosen pages (sizes and placements) and the chosen time slices (durations and interleavings) significantly impact the efficiency of the system, esp. due to their impact on fragmentation. Internal fragmentation corresponds to allocated resources whose effective usage is only partial and thus suboptimal (e.g., unused bytes within a page and useless spinning within a CPU time slice). External fragmentation corresponds to idle resources that cannot be efficiently leveraged due to their lack of sufficient contiguity in space or time (i.e., their allocation may require an expensive reorganization of other surrounding resources or has overheads that cannot be amortized at a fine granularity).

Last but not least, both subsystems require similar properties, such as *liveness* and *safety*.

## 4 CRAZY

**Architecture.** Figure 4 shows the architecture of CRAZY, which should be interpreted with reference to the architecture of traditional systems (Figure 1).

In CRAZY, the interfaces `FP Mem` and `FP CPU` from the traditional architecture (Figure 1) are unified into a single interface, `FP`.
<figure><img src="image_7.png" /><figcaption>**Figure 4.** CRAZY Architecture.</figcaption></figure>

LLF CPU and LLF Mem are consolidated into $FP_{LL}$ in CRAZY, providing a common FP-based interface for both resource types. Notice the transition from LLFs, which are complete functions, to FP's, which are merely signatures. This change is essential to propose a unified interface in CRAZY. Their implementation will specialize them either for CPU or for memory. Similarly, the OCF CPU and OCF Mem are merged into a unified OCF interface in CRAZY.

FP and OCF functions operate on unified data structures (e.g., struct virt_resource, struct phy_resource), which can encapsulate either CPU or memory management data.

In CRAZY, the OCF is supported by a central Dispatcher, which dynamically invokes the appropriate memory or CPU-specific implementations of the FP, $FP_{LL}$ and internals.

To handle interrupts, CRAZY includes a unified interrupt handling module. The latter only processes the top halves of the interrupt handlers. The bottom halves are implemented within the unified interfaces or internals and are invoked as necessary by the Dispatcher.

<table><caption>**Table 3.** An overview of CRAZY's interface.</caption><thead><tr><td>Resource-mapping functions</td><td>State-change handler functions</td></tr></thead><tbody><tr><td>selectphys_to_virt</td><td>on Yield</td></tr><tr><td>select_virt_to_evict</td><td>on ready</td></tr><tr><td>get_context</td><td>on invalid</td></tr><tr><td>save_context</td><td>on protection_violation</td></tr><tr><td>restore_context</td><td>on sleep_state_change</td></tr></tbody></table>

**Unified Interface.** We present a subset of the CRAZY interface, organized into categories based on their purpose. Functions responsible for making decisions about assigning physical resources to virtual resources are listed in Table 3 left, while functions that provide information about the state of virtual and physical resources are presented in Table 3 right.

For illustration, the function select_virt_to_evict is used to identify a virtual resource that has been utilizing a physical resource for too long. This function is typically invoked whenever there is a change in the state of virtual or physical resources to ensure that no virtual resource monopolizes a physical resource, thereby preventing other virtual resources from being assigned to it.

All these functions communicate through a common crazy_event structure. The crazy_event structure primarily holds the identifier of the virtual or physical resource concerned by the function call. Using this identifier, Dispatcher determines the type of resource involved and processes the event accordingly.

## 5 Implementation

We implemented CRAZY by unifying two semimicrokernels [18]: ghOSt [15] and USM (not yet published, somewhat similar to ExtMem [16]). ghOSt enables writing scheduling policies in user space, while USM allows writing MM policies in user space. ghOSt was developed at Google and Stanford University, while USM was developed within our research team. Both systems follow the current trend of Linux microkernelization [15, 16, 18–20] to bypass its internal subsystems, which hardcode highly generic policies that are suboptimal for most workloads.

We chose to prototype CRAZY by unifying these two systems as a fast-track approach since fully rearchitecting Linux is beyond the scope of a research project.

By applying the CRAZY concept to ghOSt and USM, we successfully merged them into a unified system. To achieve this integration, we decided to use ghOSt as the base system, integrating USM into ghOSt to create a unified CPU and memory management system. We call this prototype CRAZYOS, implemented as follows.

We rewrote the ghOSt interface and event/transaction management module to make it compatible with both CPU and memory management policy writing. This rewrite mainly involved modifying data types and function names, which were CPU-oriented, to be more generic, aligning with the unified interface we presented earlier. This rewriting affected approximately 568 lines of code (LOC).

Next, we implemented the Dispatcher, which differentiates between CPU and memory-related events and commands. The event and transaction data types were extended to include the type of resource being managed. The Dispatcher was implemented in user space and consists of approximately 1,664 LOC.

In kernel space, we routed memory events through the communication channels already established by ghOSt
for CPU events. These channels now handle events for both resource types.

In total, the unified system CRAZYOS has ~7,200 LOC, which represents 37% less than the combined size of the vanilla ghOSt (~7,000 LOC) and USM (~4,500 LOC) systems.

# 6 Preliminary Results

CRAZY unlocks several unexpected opportunities.

**Same Management Policies.** One such opportunity lies in using the same implementation of a policy for both CPU and memory management. With the unified API, it becomes possible to implement a scheduling algorithm and evaluate its performance in MM. To explore this potential, we implemented several policies in CRAZYOS, ranging from simple ones (Random, Round Robin, and FIFO) to more complex ones such as the Completely Fair Scheduler [3] (CFS) using the unified API.

For illustration, consider CFS. This policy, originally designed for CPU scheduling, can seamlessly be repurposed for memory management, specifically for selecting pages to swap out.

For this crossover application, we adapted the concept of vruntime in CPU scheduling to memory management. To this end, we use the “hotness” of a page — often defined as a function of the number of times the page is accessed — to serve as an equivalent metric to vruntime. Just as CFS selects the kThread with the least vruntime, a memory management system can select the page with the least “hotness” to swap out, thereby minimizing performance overhead.

**Same Properties.** Another example is the formal verification of policies. While considerable research has been conducted on verifying schedulers [17, 21], very little attention has been given to verifying memory management policies, despite both subsystems having comparable levels of criticality. With a unified interface, efforts directed at verifying schedulers can directly benefit the verification of memory management policies.

This effort is currently underway on CRAZYOS, leveraging Ipanema [17].

# 7 Conclusion

We identified the conceptual similarities between CPU and MM subsystems and proposed their unification under a generalized resource mapping framework called CRAZY. We are currently developing several use cases to illustrate the relevance of CRAZY.

# Acknowledgments

We thank the anonymous reviewers for their insightful feedback. This work has been partially funded by: the CNRS MLNS2 International Research Project (IRP), the

ANR "PEPR Cloud - DiVa Project" (ANR-23-PECL-0004), ANR "GenBlock" (ANR-21-CE25-0021-04) and by Inria "Défi OS".

# References

[1] [n. d.]. Advanced Configuration and Power Interface (ACPI) Specification (Accessed on 13/01/25). ([n. d.]). https://uefi.org/htmlspecs/ACPI_Spec_6_4.html

[2] [n. d.]. Arm big.LITTLE (Accessed on 13/01/25). ([n. d.]). https://www.arm.com/technologies/big-little

[3] [n. d.]. CFS Scheduler (Accessed on 13/01/25). ([n. d.]). https://docs.kernel.org/scheduler/sched-design-CFS.html

[4] [n. d.]. cgroup(7) - Linux manual page (Accessed on 13/01/25). ([n. d.]). https://man7.org/linux/man-pages/man7/cgroups.7.html

[5] [n. d.]. Memory Areas (Accessed on 13/01/25). ([n. d.]). https://litux.nl/mirror/kerneldevelopment/0672327201/ch14lev1sec2.html

[6] [n. d.]. Memory management subsystem (Accessed on 13/01/25). ([n. d.]). https://github.com/torvalds/linux/tree/master/mm

[7] [n. d.]. mlock(2) - Linux manual page (Accessed on 13/01/25). ([n. d.]). https://man7.org/linux/man-pages/man2/mlock.2.html

[8] [n. d.]. mmap(2) - Linux manual page (Accessed on 13/01/25). ([n. d.]). https://man7.org/linux/man-pages/man2/mmap.2.html

[9] [n. d.]. munmap(2) - Linux manual page (Accessed on 13/01/25). ([n. d.]). https://linux.die.net/master/2/munmap

[10] [n. d.]. namespaces(7) - Linux manual page (Accessed on 13/01/25). ([n. d.]). https://man7.org/linux/man-pages/man7/namespaces.7.html

[11] [n. d.]. Scheduling subsystem (Accessed on 13/01/25). ([n. d.]). https://github.com/torvalds/linux/tree/master/kernel/sched

[12] [n. d.]. seccomp(2) - Linux manual page (Accessed on 13/01/25). ([n. d.]). https://man7.org/linux/man-pages/man2/seccomp.2.html

[13] Bao Bui, Djob Mvondo, Boris Teabe, Kevin Jiokeng, Lavoisier Wapet, Alain Tchana, Gaël Thomas, Daniel Hagimont, Gilles Muller, and Noel DePalma. 2019. When eXtended Para - Virtualization (XPV) Meets NUMA. In *Proceedings of the Fourteenth EuroSys Conference 2019 (EuroSys '19)*. Association for Computing Machinery, New York, NY, USA, Article 7, 15 pages. https://doi.org/10.1145/3302424.3303960

[14] Victor Costan and Srinivas Devadas. 2016. Intel SGX Explained. Cryptology ePrint Archive, Paper 2016/086. (2016). https://eprint.iacr.org/2016/086

[15] Jack Tigar Humphries, Neel Natu, Ashwin Chaugule, Ofir Weisse, Barret Rhoden, Josh Don, Luigi Rizzo, Oleg Rombakh, Paul Turner, and Christos Kozyakis. 2021. ghOSt: Fast & Flexible User-Space Delegation of Linux Scheduling. In *Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles (SOSP '21)*. Association for Computing Machinery, New York, NY, USA, 588–604. https://doi.org/10.1145/3477132.3483542

[16] Sepehr Jalalian, Shaurya Patel, Milad Rezaei Hajidehi, Margo Seltzer, and Alexandra Fedorova. 2024. ExtMem: Enabling Application-Aware Virtual Memory Management for Data-Intensive Applications. In *2024 USENIX Annual Technical Conference (USENIX ATC 24)*. USENIX Association, Santa Clara, CA, 397–408. https://www.usenix.org/conference/atc24/presentation/jalalian

[17] Baptiste Lepers, Redha Gouicem, Damien Carver, Jean-Pierre Lozi, Nicolas Palix, Maria-Virginia Aponte, Willy Zwaenepoel, Julien Sopena, Julia Lawall, and Gilles Muller. 2020. Provable multicore schedulers with Ipanema: application to work conservation. In *Proceedings of the Fifteenth European Conference*
on Computer Systems (EuroSys '20). Association for Computing Machinery, New York, NY, USA, Article 3, 16 pages. https://doi.org/10.1145/3342195.3387544

[18] Jing Liu, Anthony Rebello, Yifan Dai, Chenhao Ye, Sudarsun Kanan, Andrea C. Arpaci-Dusseau, and Remzi H. Arpaci-Dusseau. 2021. Scale and Performance in a Filesystem Semi-Microkernel. In *Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles (SOSP '21)*. Association for Computing Machinery, New York, NY, USA, 819–835. https://doi.org/10.1145/3477132.3483581

[19] Michael Marty, Marc de Kruijf, Jacob Adriaens, Christopher Alfeld, Sean Bauer, Carlo Contavalli, Michael Dalton, Nandita Dukkipati, William C. Evans, Steve Gribble, Nicholas Kidd, Roman Kononov, Gautam Kumar, Carl Mauer, Emily Musick, Lena Olson, Erik Rubow, Michael Ryan, Kevin Springborn, Paul Turner, Valas Valancius, Xi Wang, and Amin Vahdat. 2019. Snap: a micro-kernel approach to host networking. In *Proceedings of the 27th ACM Symposium on Operating Systems Principles (SOSP '19)*. Association for Computing Machinery, New York, NY, USA, 399–413. https://doi.org/10.1145/3341301.3359657

[20] Samantha Miller, Kaiyuan Zhang, Mengqi Chen, Ryan Jennings, Ang Chen, Danyang Zhuo, and Thomas Anderson. 2021. High Velocity Kernel File Systems with Bento. In *19th USENIX Conference on File and Storage Technologies (FAST 21)*. USENIX Association, 65–79. https://www.usenix.org/conference/fast21/presentation/miller

[21] G. Muller, J.L. Lawall, and H. Duchesne. 2005. A framework for simplifying the development of kernel schedulers: design and performance evaluation. In *Ninth IEEE International Symposium on High-Assurance Systems Engineering (HASE'05)*. 56–65. https://doi.org/10.1109/HASE.2005.1

[22] Steven Pelley, Thomas F. Wenisch, Brian T. Gold, and Bill Bridge. 2013. Storage management in the NVRAM era. *Proc. VLDB Endow.* 7, 2 (Oct. 2013), 121–132. https://doi.org/10.14778/2732228.2732231

[23] Yan Sun, Yifan Yuan, Zeduo Yu, Reese Kuper, Chihun Song, Jinghan Huang, Houxiang Ji, Siddharth Agarwal, Jiaqi Lou, Ipoom Jeong, Ren Wang, Jung Ho Ahn, Tianyin Xu, and Nam Sung Kim. 2023. Demystifying CXL Memory with Genuine CXL-Ready Systems and Devices. In *Proceedings of the 56th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO '23)*. Association for Computing Machinery, New York, NY, USA, 105–121. https://doi.org/10.1145/3613424.3614256