The NIC should be part of the OS

Pengcheng Xu; Timothy Roscoe

REVIEW 4 major objections 4 minor 24 references

The NIC should be part of the OS

T0 review · 4 major / 4 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A cache-coherent NIC that is trusted by the OS can dispatch RPCs with near-zero CPU overhead, the paper claims.

desk verdict A real OS/NIC architecture proposal whose abstract overclaims performance; the missing threat model is the load-bearing weakness, but the design deserves serious review. read the letter →

arxiv 2501.10138 v2 pith:FE6ZELCW submitted 2025-01-17 cs.OS cs.ARcs.NI

Pengcheng Xu , Timothy Roscoe This is my paper · ORCID

classification cs.OScs.ARcs.NI

keywords networkinterfacecardremoteprocedurecallcache-coherentinterconnectkernelbypassoperatingsystemssmartNICschedulingstateserverlesscomputing

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper argues that the received wisdom of a trade-off between speed and flexibility in server networking is wrong, and that its persistence is a design accident: a split of system state between the OS and the NIC. The authors claim that if the NIC is treated as a trusted component of the OS and connected over a cache-coherent interconnect, it can hold live scheduling state and perform the whole receive path, from packet decode to function dispatch, on its own hardware. A worker core then does no work at all: a load instruction stalls until the NIC fills the cache line with the RPC arguments and the address of the handler to jump to. If this works, small RPC workloads can get better performance than the fastest kernel-bypass stacks while keeping the OS in charge of scheduling, load balancing, and dynamic core allocation. The paper is a system design and prototype-in-progress, not a finished evaluation.

What carries the argument

The load-bearing object is Lauberhorn, the authors' prototype smart NIC, which uses a cache-coherent interconnect to speak a protocol with the CPU: each communication end-point is a set of cache lines homed on the NIC, and a process receives a request by loading one control line, stalling until the NIC answers with a cache line carrying the dispatch information. The same fine-grained mechanism carries kernel scheduling state to the NIC, letting it steer packets to the right process and ask the OS to reschedule; a 15 ms TryAgain response is used to avoid coherence-protocol 'bus errors' when no packet is pending. This protocol does the work of demultiplexing, deserializing, scheduling, and context-switching that conventional stacks spread across DMA, interrupts, and the kernel.

What would settle it

Run the Lauberhorn receive path with RPC interarrival times that straddle the 15 ms TryAgain timeout while the target core is stalled. If the TryAgain response causes the NIC to miss a request, or if a packet arriving just after TryAgain triggers a coherence-protocol bus error or an unbounded stall, the zero-software-overhead dispatch claim fails. A second check: attempt to dispatch a request to a process whose scheduling state is stale in the NIC; if the NIC steers to the wrong core or corrupts scheduling metadata, the trust assumption fails.

Watch

Extended reading notes

Core claim

The central claim is that a NIC integrated into the OS can execute every step of turning an incoming packet into a function invocation, so that the only CPU action left is a stalled load that returns a prepared cache line: the arguments and the virtual address of the target function's first instruction. The paper attributes the current performance/flexibility trade-off to an arbitrary boundary in which the NIC demultiplexes flows while the OS owns scheduling state; once the NIC is trusted and shares that state, the boundary disappears. The authors assert this yields better RPC performance than kernel-bypass systems while retaining the dynamic adaptation of kernel-based stacks. They do not claim this for large transfers, which they say are better handled by DMA once throughput dominates latency.

Load-bearing premise

The load-bearing premise is that a NIC can be trusted as part of the OS and can safely hold and use live kernel scheduling state delivered over the cache-coherent interconnect; if that trust model, or the coherence-stall mechanism's 15 ms TryAgain timeout, fails, the fast path collapses and the claimed performance does not follow.

Editorial extensions

If this is right

Small RPC and serverless workloads could run at kernel-bypass speed without dedicating cores or busy-waiting, since blocked cores stall on loads instead of spinning.
The OS can keep scheduling authority and dynamic load balancing while the NIC steers packets, so static queue-to-core bindings are no longer required for high performance.
Non-preemptive and preemptive kernels can both reallocate cores between RPC services and other work, because the NIC can retire a blocked kernel thread with a message.
Large messages revert to DMA-based transfers, so the design targets the common small-RPC case without pretending to replace bulk-data paths.
The same OS-NIC control channel can expose load statistics to the scheduler, enabling NIC-driven dynamic scaling of cores allocated to services.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

If the trust model holds, the same mechanism could be generalized beyond RPC to any event-driven dispatch where the completion is a small, well-defined data structure, such as timers, I/O completions, or serverless function triggers.
Making the NIC a trusted scheduler state holder implies a new security boundary: a compromised or defective NIC could read or corrupt live scheduling state, so the approach likely needs stronger attestation or isolation than the sketch addresses.
The 15 ms TryAgain timeout is a hand-picked parameter; a natural extension is to make the timeout adaptive to measured request-arrival statistics, which would test whether the stall mechanism preserves correctness under bursty traffic.
The proposed dispatch changes the performance model of RPC from 'wake a core and run a stack' to 'park a core on a cache line', which suggests that the optimal number of cores to allocate to a service could be derived from the NIC's queue occupancy rather than from CPU utilization.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Pengcheng — read it before the discussion. It’s a real architectural proposal, not a variation on kernel bypass; it's also a position paper with zero end-to-end measurements, and the abstract goes past what the paper shows.

The new idea: a cache-coherent NIC that is a full, trusted OS component — it holds a copy of the scheduler run-queue state, decodes RPCs, and answers a processor’s stalled load with the target code pointer and arguments. Prior work (CC-NIC, nanoPU) either keeps the NIC as a device or co-locates it with a fixed core schedule; here the hardware/software split itself is what’s rejected. That is a clear, well-argued departure, and the related work is placed carefully.

It is also honest about being unfinished. The prototype (Lauberhorn) is sketched but there are no RPC benchmarks, no kernel-bypass comparison, and no error bars. Figure 2 is interconnect round-trip latency, not an RPC path. So the abstract’s claim about beating kernel bypass is a research target, not a result. A HotOS paper can make that move, but the framing should have said “targets” rather than “can achieve.”

The soft spot the stress-test note hits is the trust model. “It’s time to trust the NIC” does not address what happens when a NIC exposed to hostile traffic holds a list of jump targets and the authority to trigger preemption. The paper gives no threat model, no confinement mechanism for the NIC’s access to scheduling state, and no discussion of a buggy NIC corrupting a code pointer. That is load-bearing, not an optional security appendix. The 15ms TryAgain timeout handles coherence protocol timeouts, but not integrity. This is the section to push on in revision.

Minor issues: the hot-services-less-than-cores assumption is asserted; the 4KiB DMA threshold is given without measurement; and the self-citation to [21] is fine, but the paper will need to show how the endpoint protocol scales beyond one cache line.

Altogether: send it to referees, but frame it as a research proposal. The ideas are worth serious discussion, and the team is actually building the thing, so it isn’t vapor. A serious referee should push the authors to soften the abstract and add a threat-model paragraph — both are achievable.

Referee Report

4 major / 4 minor

Summary. This position paper argues that the conventional split in system state between OS and NIC is the root cause of the kernel-bypass trade-off between performance and flexibility. The authors propose making the NIC a trusted OS component that, using cache-coherent interconnects such as CXL and ECI, can perform the entire RPC receive path - demultiplexing, unmarshalling, scheduling-state lookup, and function dispatch - by returning a prepared cache line to a stalled CPU load, with near-zero CPU overhead. The architecture is embodied in the Lauberhorn prototype on the Enzian platform, and the paper presents the receive fast path, the mechanism for sharing scheduling state, and a comparison of interconnect round-trip latencies (Figure 2). Section 6 explicitly acknowledges that the work is at an early stage, listing missing non-functional features and open research questions.

Significance. If the central claims were borne out, the paper would make a significant contribution to systems research: it directly challenges the widely accepted trade-off between kernel-bypass performance and dynamic scheduling flexibility, and it gives a concrete, testable design based on real cache-coherent interconnects and a working research platform (Enzian). The paper is also honest about its status as work in progress, and it names specific limitations in Section 6. The main strength is the architectural vision and the concrete protocol sketch; the main weakness is that the headline performance and robustness claims are not yet supported by end-to-end measurements, a threat model, or correctness evidence.

major comments (4)

[Abstract and Section 4] The abstract's central claim that the approach delivers 'performance for RPC workloads better than the fastest kernel-bypass approaches' is not supported by any RPC benchmark or end-to-end measurement. Figure 2 reports only 64-byte message round-trip latencies over the interconnect, which is not the cost of the full RPC path (steps 1–12 of Section 2). To support the claim, the paper needs at least a microbenchmark of the complete receive path from packet arrival to handler invocation, with a comparison to a kernel-bypass baseline (e.g., DPDK or a dedicated polling stack) and appropriate error bars. As it stands, the central performance claim is an aspiration rather than a result.
[Section 4, 'it's time to trust the NIC'] The paper gives the NIC access to live kernel scheduling state and the ability to deliver a cache line whose contents are used as a jump target, yet it provides no threat model or isolation mechanism for a device that is exposed to untrusted network traffic. The abstract's claim that this is achieved 'without sacrificing the robustness and dynamic adaptation of kernel-based network subsystems' requires that a buggy or malicious NIC cannot forge a dispatch cache line or corrupt the scheduler state it is allowed to touch. The assertion in Section 4 that communication is 'easily protected using conventional MMU mechanisms' does not address the fact that the NIC itself becomes a privileged agent; please provide a concrete mechanism (e.g., capability-based delegation, IOMMU-enforced restrictions on NIC-accessible memory, or a formal trust boundary) and state which parts of the kernel state the NIC may read or write.
[Section 5.1, TryAgain timeout] The TryAgain dummy message after 15 ms is a hand-chosen parameter with no analysis of its effect on performance or correctness. If the timeout is too short, the core is frequently unblocked and must reload, reintroducing the very spinning and bus traffic the design seeks to avoid; if too long, the coherence stall may cause bus errors or latency anomalies. The paper also does not specify how TryAgain interacts with a real packet that arrives just after the dummy response, or how the NIC guarantees that the subsequent reload will not be starved. Please provide an analysis or measurement of this trade-off, and ideally make the timeout adaptive or derived from coherence-protocol parameters.
[Section 6, correctness claim] The statement that the design 'can be model-checked for correctness relatively easily' is not backed by any TLA+ specification, model-checking run, or even an explicit list of invariants. Since the fast path relies on a stalled load returning a jump target while the scheduler may concurrently change run queues and page tables, the correctness of the race handling is load-bearing for the 'robustness' part of the central claim. Please include at least a fragment of the specification or a precise statement of the invariants that are checked, and report the model-checking result.

minor comments (4)

[Figure 2] The plot shows three latency bars but no methodology, no error bars, and no sample size; please add a short description of how the round-trip latencies were measured and over how many trials.
[Section 5.1, paragraph on control cache lines] The sentence 'the NIC with respond to this load' contains a typo; it should read 'will respond to this load'.
[Section 5.1, address space handling] The text states that after the stalled load returns, 'the CPU ... is already in the correct address space,' but it does not explain how the address space is switched or how the NIC knows which page table is active. Please clarify the mechanism, especially for the case where the target process is not the currently running process.
[References] The paper relies heavily on the protocol from reference [21] for cache-line delivery; please cite this more explicitly in Section 5.1 where the protocol is first described, so that a reader can distinguish what is adopted from prior work and what is new in Lauberhorn.

Circularity Check

0 steps flagged · score 2.0 of 10

No circular derivation: the paper is a position/architecture sketch with no fitted predictions; minor self-citations are not load-bearing.

full rationale

The paper contains no equations, no fitted parameters, and no statistical prediction that could reduce to its own inputs. Its central claim — that integrating the NIC into the OS as a trusted component with access to scheduling state can beat kernel-bypass for RPC workloads — is a forward architectural prediction, not a derivation from data. The only quantitative evidence, the round-trip latency comparison in Figure 2, is a measurement on the authors' Enzian platform and is cited as motivation rather than as the conclusion. Self-citations appear: the Enzian platform [5], prior Arrakis work [18], and the cache-line delivery protocol of Ruzhanskaia et al. [21], whose authors include Xu, Cock, and Roscoe. Of these, [21] is the most load-bearing because Section 5.1 states the dispatch path 'uses an extension of the protocol described by Ruzhanskaia et al. [21]'. However, the paper's contribution is the combination of that mechanism with fine-grained OS scheduling state and the argument that the NIC should be trusted; the cited protocol is a building block, not the result being proved. There is no uniqueness theorem, no ansatz smuggled in through citation, and no renaming of a known result. The abstract's strong performance claim is unsupported by measurements in this paper, but that is a correctness/evidence concern, not circularity. Accordingly, the paper has no significant circularity; at most it carries a minor, non-load-bearing self-citation, giving a score of 2.

Assumptions & free parameters 2 free parameters · 5 assumptions · 2 invented entities

The ledger is mostly assumptions and hand-chosen design parameters. The heaviest burdens are the trust assumption and the coherence-stall assumption, both of which are asserted rather than demonstrated.

free parameters (2)

TryAgain timeout = 15 ms
Chosen by hand in Section 5.1 to avoid coherence-protocol bus errors when the NIC stalls a CPU load; correctness and energy claims depend on this value without measurement.
DMA fallback threshold = ~4 KiB
Stated as an empirical value for Enzian in Section 6; used to decide when to switch from cache-line delivery to DMA, though no measurements or error bars support it.

assumptions (5)

domain assumption The NIC can be treated as a trusted OS component with access to scheduling state.
Stated in Sections 3 and 4 as a reversal of the current IOMMU-based trust model; no security analysis of a compromised NIC is given.
domain assumption Cache-coherent interconnects such as CXL.mem 3.0 or ECI allow a device to home cache lines and stall a CPU load until data is ready, with acceptable timeout behavior.
Used throughout Section 5; the TryAgain mechanism is the only mitigation for coherence timeouts, and no working implementation validates it.
domain assumption The kernel and NIC can maintain a consistent, low-overhead view of which core is running which process, and this state remains accurate across context switches.
Required for the fast path in Sections 4 and 5.2; the paper sketches updates via the interconnect but does not prove bounds on staleness.
domain assumption The NIC can demultiplex, decrypt, decompress, and unmarshal arbitrary RPC requests at line rate using existing offload techniques.
Invoked in Sections 4 and 5.1 as an extension of prior accelerators, with no design for handling heterogeneous serialization formats.
domain assumption Most RPC requests and responses are small, so the cache-line fast path dominates.
Cites Seemakhupt et al. [23] and states the goal in Section 1; if small-message traffic is not dominant, the 4 KiB DMA fallback is invoked.

invented entities (2)

Lauberhorn smart NIC
purpose: FPGA-based prototype NIC that homes cache lines, decodes RPCs, and cooperates with the OS scheduler to dispatch requests directly to application code.
Described in Sections 4 and 5 as work in progress; no hardware, bitstream, or benchmarks are provided, so there is no falsifiable handle outside the paper.
RPC isolation domain
purpose: Per-process endpoint abstraction with dedicated control cache lines that lets the NIC deliver a request to a user process without kernel intervention.
Introduced in Section 5.2 and Figure 5; it is a new abstraction defined by the paper, and its interface is still listed as an open question in Section 6.

how reviews work

0 comments

Cite this review

Pith. "Pith review of The NIC should be part of the OS." pith.science (2026). https://pith.science/paper/FE6ZELCW

@misc{pith2026250110138,
  author       = {Pith},
  title        = {Pith review of: The NIC should be part of the OS},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/FE6ZELCW}},
  note         = {Machine review of arXiv:2501.10138}
}

read the original abstract

The network interface adapter (NIC) is a critical component of a cloud server occupying a unique position. Not only is network performance vital to efficient operation of the machine, but unlike compute accelerators like GPUs, the network subsystem must react to unpredictable events like the arrival of a network packet and communicate with the appropriate application end point with minimal latency. Current approaches to server stacks navigate a trade-off between flexibility, efficiency, and performance: the fastest kernel-bypass approaches dedicate cores to applications, busy-wait on receive queues, etc. while more flexible approaches appropriate to more dynamic workload mixes incur much greater software overhead on the data path. However, we reject this trade-off, which we ascribe to an arbitrary (and sub-optimal) split in system state between the OS and the NIC. Instead, by exploiting the properties of cache-coherent interconnects and integrating the NIC closely with the OS kernel, we can achieve something surprising: performance for RPC workloads better than the fastest kernelbypass approaches without sacrificing the robustness and dynamic adaptation of kernel-based network subsystems.

Figures

Figures reproduced from arXiv: 2501.10138 by the authors.

**Figure 2.** 64-byte message round-trip latencies. memory accesses on behalf of a remote peer, using an authorization framework that is naive at best in multi-tenant scenarios. A more OS-centric perspective on RDMA-like functionality views the NIC as providing to the OS additional, specialized cores close to the network interface which can execute a limited number of RPC operations. A related factor is that architecture resear… view at source ↗

**Figure 3.** Overview of the Lauberhorn receive path. Firstly, new cache-coherent peripheral interconnects between devices and cores can radically change communication between CPU and NIC. Examples are CXL.mem 3.0 [6], CCIX [4], and the Enzian Coherence Interface (ECI) [5]. Crucially, this allows lightweight signaling to the device: a NIC can interpret cache operations on certain addresses as specific signals or requests, and… view at source ↗

Figures from the paper (2 more)

**Figure 4.** Figure 4: The Lauberhorn protocol between NIC and CPU a variation of existing NIC techniques like protocol offload and RPC deserialization acceleration (e.g. [19]). In the FPGA implementation, an Ethernet frame streams in from the Ethernet MAC IP block and passes through various…

**Figure 5.** Figure 5: Comparison between normal task scheduling and NIC-driven scheduling of RPC isolation domains. [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

24 extracted references · 23 canonical work pages

[21]

Rethinking Pro- grammed I/O for Fast Devices, Cheap Cores, and Coherent Intercon- nects, Sept

Ruzhanskaia, A., Xu, P., Cock, D., and Roscoe, T. Rethinking Pro- grammed I/O for Fast Devices, Cheap Cores, and Coherent Intercon- nects, Sept. 2024. arXiv:2409.08141 [cs]

arXiv 2024
[1]

The Security Design of the A WS Nitro System, Nov

Amazon Web Services. The Security Design of the A WS Nitro System, Nov. 2022. https://docs.aws.amazon.com/whitepapers/latest/security- design-of-aws-nitro-system/security-design-of-aws-nitro- system.html

work page 2022
[2]

The Rocket Chip Generator

Asanović, K., Avizienis, R., Bachrach, J., Beamer, S., Biancolin, D., Celio, C., Cook, H., Dabbelt, D., Hauser, J., Izraelevitz, A., Karandikar, S., Keller, B., Kim, D., and Koenig, J. The Rocket Chip Generator

work page
[3]

Ix: a protected dataplane operating system for high throughput and low latency

Belay, A., Prekas, G., Klimovic, A., Grossman, S., Kozyrakis, C., and Bugnion, E. Ix: a protected dataplane operating system for high throughput and low latency. In Proceedings of the 11th USENIX Conference on Operating Systems Design and Implementation (USA, 2014), OSDI’14, USENIX Association, p. 49–65

work page 2014
[4]

Cache Coherent Interconnect for Accelerators (CCIX), May 2024

CCIX Consortium and others . Cache Coherent Interconnect for Accelerators (CCIX), May 2024

work page 2024
[5]

HOTOS ’25, May 14–16, 2025, Banff, AB, Canada He, Z., Hossle, N., Korolija, D., Licciardello, M., Martsenko, K., Achermann, R., Alonso, G., and Roscoe, T

Cock, D., Ramdas, A., Schwyn, D., Giardino, M., Turowski, A., The NIC should be part of the OS. HOTOS ’25, May 14–16, 2025, Banff, AB, Canada He, Z., Hossle, N., Korolija, D., Licciardello, M., Martsenko, K., Achermann, R., Alonso, G., and Roscoe, T. Enzian: an open, general, CPU/FPGA platform for systems software. In ASPLOS ’22: Proceedings of the Twenty...

work page 2025
[6]

Compute Express Link (CXL) version 3.0, Aug

Consortium, C. Compute Express Link (CXL) version 3.0, Aug. 2022

work page 2022
[7]

Caladan: Mitigat- ing Interference at Microsecond Timescales

Fried, J., Ruan, Z., Ousterhout, A., and Belay, A. Caladan: Mitigat- ing Interference at Microsecond Timescales. pp. 281–297

work page

Show all 24 references

[8]

T., Natu, N., Chaugule, A., Weisse, O., Rhoden, B., Don, J., Rizzo, L., Rombakh, O., Turner, P., and Kozyrakis, C

Humphries, J. T., Natu, N., Chaugule, A., Weisse, O., Rhoden, B., Don, J., Rizzo, L., Rombakh, O., Turner, P., and Kozyrakis, C. ghOSt: Fast & Flexible User-Space Delegation of Linux Scheduling. In Pro- ceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles ...

2021
[9]

T., Natu, N., Kaffes, K., Novaković, S., Turner, P., Levy, H., Culler, D., and Kozyrakis, C

Humphries, J. T., Natu, N., Kaffes, K., Novaković, S., Turner, P., Levy, H., Culler, D., and Kozyrakis, C. Tide: A Split OS Architecture for Control Plane Offloading, Oct. 2024. arXiv:2408.17351

2024 arXiv
[10]

The nanoPU: A Nanosecond Network Stack for Datacenters

Ibanez, S., Mallery, A., Arslan, S., Jepsen, T., Shahbaz, M., Kim, C., and McKeown, N. The nanoPU: A Nanosecond Network Stack for Datacenters. pp. 239–256
[11]

J., Jeong, S., Heo, J., Shin, H., Ham, T

Jang, J., Jung, S. J., Jeong, S., Heo, J., Shin, H., Ham, T. J., and Lee, J. W. A Specialized Architecture for Object Serialization with Applications to Big Data Analytics. In 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA) (Valencia, Spain, M...

2020
[12]

T., Belay, A., Mazières, D., and Kozyrakis, C

Kaffes, K., Chong, T., Humphries, J. T., Belay, A., Mazières, D., and Kozyrakis, C. Shinjuku: Preemptive Scheduling for {usecond-scale} Tail Latency. pp. 345–360
[13]

A Hardware Accelerator for Protocol Buffers

Karandikar, S., Leary, C., Kennelly, C., Zhao, J., Parimi, D., Nikolic, B., Asanovic, K., and Ranganathan, P. A Hardware Accelerator for Protocol Buffers. In MICRO-54: 54th Annual IEEE/ACM International Symposium on Microarchitecture (Virtual Event Greece, Oct. 2021), ACM, pp. 462–478

2021
[14]

C., Gribble, S., Kidd, N., Kononov, R., Kumar, G., Mauer, C., Musick, E., Olson, L., Rubow, E., Ryan, M., Springborn, K., Turner, P., V alancius, V., W ang, X., and V ahdat, A

Marty, M., de Kruijf, M., Adriaens, J., Alfeld, C., Bauer, S., Con- tavalli, C., Dalton, M., Dukkipati, N., Evans, W. C., Gribble, S., Kidd, N., Kononov, R., Kumar, G., Mauer, C., Musick, E., Olson, L., Rubow, E., Ryan, M., Springborn, K., Turner, P., V alancius, V., W ang, X....

2019
[15]

Mind the Gap: Reconnecting Architecture and OS Research

Mogul, J., Baumann, A., Roscoe, T., and Soares, L. Mind the Gap: Reconnecting Architecture and OS Research. In Proceedings of the 13th Workshop on Hot Topics in Operating Systems (HotOS-XIII) (Napa, CA, USA, May 2011)

2011
[16]

Mogul, J. C. TCP offload is a dumb idea whose time has come. In 9th Workshop on Hot Topics in Operating Systems (HotOS IX) (Lihue, HI, May 2003), USENIX Association

2003
[17]

Shenango: Achieving High {CPU} Efficiency for Latency-sensitive Datacenter Workloads

Ousterhout, A., Fried, J., Behrens, J., Belay, A., and Balakrishnan, H. Shenango: Achieving High {CPU} Efficiency for Latency-sensitive Datacenter Workloads. pp. 361–378
[18]

Peter, S., Li, J., Zhang, I., Ports, D. R. K., Woos, D., Krishnamurthy, A., Anderson, T., and Roscoe, T. Arrakis: The Operating System is the Control Plane. In 11th Symposium on Operating Systems Design and Implementation (OSDI’14) (Broomfield, Colorado, USA, October 2014)

2014
[19]

P., Falsafi, B., and Koch, C

Pourhabibi, A., Gupta, S., Kassir, H., Sutherland, M., Tian, Z., Dru- mond, M. P., Falsafi, B., and Koch, C. Optimus Prime: Accelerating Data Transformation in Servers. In Proceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Lan- gu...

2020
[20]

Cere- bros: Evading the RPC Tax in Datacenters

Pourhabibi, A., Sutherland, M., Daglis, A., and Falsafi, B. Cere- bros: Evading the RPC Tax in Datacenters. In MICRO-54: 54th Annual IEEE/ACM International Symposium on Microarchitecture(Virtual Event Greece, Oct. 2021), ACM, pp. 407–420

2021
[22]

N., Krishnamurthy, A., Culler, D., Levy, H

Schuh, H. N., Krishnamurthy, A., Culler, D., Levy, H. M., Rizzo, L., Khan, S., and Stephens, B. E. CC-NIC: a Cache-Coherent Interface to the NIC. In Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, V...

2024
[23]

E., Khan, S., Liu, S., W assel, H., Yeganeh, S

Seemakhupt, K., Stephens, B. E., Khan, S., Liu, S., W assel, H., Yeganeh, S. H., Snoeren, A. C., Krishnamurthy, A., Culler, D. E., and Levy, H. M. A Cloud-Scale Characterization of Remote Procedure Calls. In Proceedings of the 29th Symposium on Operating Systems Principles (Ko...

2023
[24]

Zhang, I., Raybuck, A., Patel, P., Olynyk, K., Nelson, J., Leija, O. S. N., Martinez, A., Liu, J., Simpson, A. K., Jayakar, S., Penna, P. H., Demoulin, M., Choudhury, P., and Badam, A. The Demikernel Dat- apath OS Architecture for Microsecond-scale Datacenter Systems. In Proce...

2021

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.

[1] [21]

Rethinking Pro- grammed I/O for Fast Devices, Cheap Cores, and Coherent Intercon- nects, Sept

Ruzhanskaia, A., Xu, P., Cock, D., and Roscoe, T. Rethinking Pro- grammed I/O for Fast Devices, Cheap Cores, and Coherent Intercon- nects, Sept. 2024. arXiv:2409.08141 [cs]

arXiv 2024

[2] [1]

The Security Design of the A WS Nitro System, Nov

Amazon Web Services. The Security Design of the A WS Nitro System, Nov. 2022. https://docs.aws.amazon.com/whitepapers/latest/security- design-of-aws-nitro-system/security-design-of-aws-nitro- system.html

work page 2022

[3] [2]

The Rocket Chip Generator

Asanović, K., Avizienis, R., Bachrach, J., Beamer, S., Biancolin, D., Celio, C., Cook, H., Dabbelt, D., Hauser, J., Izraelevitz, A., Karandikar, S., Keller, B., Kim, D., and Koenig, J. The Rocket Chip Generator

work page

[4] [3]

Ix: a protected dataplane operating system for high throughput and low latency

Belay, A., Prekas, G., Klimovic, A., Grossman, S., Kozyrakis, C., and Bugnion, E. Ix: a protected dataplane operating system for high throughput and low latency. In Proceedings of the 11th USENIX Conference on Operating Systems Design and Implementation (USA, 2014), OSDI’14, USENIX Association, p. 49–65

work page 2014

[5] [4]

Cache Coherent Interconnect for Accelerators (CCIX), May 2024

CCIX Consortium and others . Cache Coherent Interconnect for Accelerators (CCIX), May 2024

work page 2024

[6] [5]

HOTOS ’25, May 14–16, 2025, Banff, AB, Canada He, Z., Hossle, N., Korolija, D., Licciardello, M., Martsenko, K., Achermann, R., Alonso, G., and Roscoe, T

Cock, D., Ramdas, A., Schwyn, D., Giardino, M., Turowski, A., The NIC should be part of the OS. HOTOS ’25, May 14–16, 2025, Banff, AB, Canada He, Z., Hossle, N., Korolija, D., Licciardello, M., Martsenko, K., Achermann, R., Alonso, G., and Roscoe, T. Enzian: an open, general, CPU/FPGA platform for systems software. In ASPLOS ’22: Proceedings of the Twenty...

work page 2025

[7] [6]

Compute Express Link (CXL) version 3.0, Aug

Consortium, C. Compute Express Link (CXL) version 3.0, Aug. 2022

work page 2022

[8] [7]

Caladan: Mitigat- ing Interference at Microsecond Timescales

Fried, J., Ruan, Z., Ousterhout, A., and Belay, A. Caladan: Mitigat- ing Interference at Microsecond Timescales. pp. 281–297

work page