EbbRT: A Framework for Building Per-Application Library Operating Systems

What kind of paper is this?

• Stands for Elastic Building Block Runtime
• Proposes, designs, implements, and evaluates a new architecture. It felt similar to the Exokernel paper in flavor.

The Story

• Once upon a time, it was shown that library operating systems have the potential to greatly improve application performance. However, building a library OS is a big effort. The authors built a framework to make building library operating systems significantly easier, and everyone lived happily ever after.

EbbRT Goals

• Applications should be able to specialize anything
• Allow library OS to run alongside a conventional OS to provide broad applicability.
• Make it easy to write systems code

Heterogeneous Distributed Structure

• EbbRT can run as either a process on a conventional OS or as a bootable runtime that can run natively on HW.
• Native runtime is a single address space, runs privileged.
• Isolation must be provided at network layer.
• Typical deployment: hosted process with potentially multiple native processes.

Modular System Structure

• EBBs encapsulate functionality behind strong interfaces
• Each EBB is a distributed multi-core fragmented object (note that two of the authors were also on the Tornado paper)
• EBB contains types on which applications can build.

Execution Model

• Non-pre-emptive and event-driven.
• Native: One event loop per core
• Hosted: Event loop uses OS services (Poll, select)
• Also provde a cooperative scheduling layer on top of events

What are these building blocks?

• Memory: Page allocator, VMemAllocator, SlabAllocator, AllPurposeAllocator
• Objects: EbbAllocator, LocalIdMap, GlobalIdMap
• Event: Event Manager, Timer
• IO: Network Manager, SharedPoolAllocator, NodeAllocator,Messenger,VirtioNet

Neat Features

• Since the whole system is event driven, restoring proper context on events can be tedious. However, C++ lambdas let you capture current state and neatly solve that problem.

What do we want the evaluation to show us?

• How easy it is to build native applications.
• How much faster you can (easily) build a native application.
• Not sure I care much about microbenchmarks, because I would not really now how to think about them.
• I am very interested in how difficult it was to port the various benchmarks to EbbRT.
• They are very artful in their analysis: instead of saying, "We are fast." they say that "EbbRT does not preclude high performance implementations."
• Results:
  • Memory Allocation: EbbRT looks pretty good (and scalable)
  • Networking: Better throughput (goodput) and latency than competitors (even OSv).
  • Memcached: (Kind of suspicious since "we re-implented memcached".) (I.e., I think they changed the hashtable implementation) and "We lack some features of the standard memcached."
  • Node.js: I really wanted a more quantitative discussion of the porting challenge! "modest development effort" OK -- 1 dev, 2 weeks, 1M lines of code, 3000 lines of new code -- that sounds pretty impressive! The cross compilation pipeline seems critical! Their scores are higher, but except for Splay, not significantly so. Is it worth is?

Feature Analysis

1. Features that are common practice
2. Features that are not used and should stay that way
3. Features that are not used but should be reconsidered
   • I loved the use of the C++ lambdas.
   • The futures sound cool too, although I didn't entirely understand them.
   • I like the ability of the EbbRT system to run both natively and hosted.
4. Features for which the jury is out
   • Fully event-driven design