EbbRT: A Framework for Building Per-Application Library Operating Systems
Schatzberg, Cadden, Dong, Krieger, Appavoo (2016)
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
- Features that are common practice
- Features that are not used and should stay that way
- 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.
- Features for which the jury is out
- Fully event-driven design