EECS 582 Midterm Review Mosharaf Chowdhury EECS 582 – F16
Stats on the PC Members (23) EECS 582 – F16
Stats on the 18 Papers We’ve Reviewed EECS 582 – F16
Stats on the 18 Papers We’ve Reviewed EECS 582 – F16
Classics EECS 582 – F16
Classics UNIX Simplicity is king when you must support diverse applications Usage-driven/user-driven design Everything is a file! System R The first relational database implementation Independence of storage and compute Find the “right” metric and do everything when you must deliver performance (i.e., specialization instead of generalization) EECS 582 – F16
Storage and File Systems EECS 582 – F16
Storage and File Systems RAID Industry standard for durable, high-performance storage Parallelize for performance and fault-tolerance One size doesn’t fit all LFS Entire file system is a sequentially-accessed log Periodically garbage collect to avoid fragmentation Great for SSDs EECS 582 – F16
Kernel EECS 582 – F16
Kernel Exokernel Multikernel Minimal kernel instead of a full-fledged one End-to-end argument: only provide services that everyone needs to balance between specialization (performance) and generalization (applicability) Multikernel Make communication explicit when you must communicate Shared-nothing design EECS 582 – F16
Kernel IX Separate control and data planes to provide I/O performance Kernels aren’t inherently slow; it’s about how we do things Commuter Interfaces impact scalable design If interface is commutative, you can find a scalable design (avoid locking and blocking among multiple dependent threads) EECS 582 – F16
Virtual Memory and RPC EECS 582 – F16
Virtual Memory and RPC Memory Coherence RPC Shared-everything design requires frequent updates Dynamic page ownership management makes decentralized solutions run faster Keeping things coherent is expensive but provides simple programming models RPC Makes distributed nature more explicit while keeping the same programming model as a non-distributed system This paper focused on hiding RPC calls No shared memory EECS 582 – F16
Concurrency and Scheduling EECS 582 – F16
Concurrency and Scheduling SEDA Thread- and event-based programming models both have their advantages and drawbacks (ease of programming vs. scalability and performance) It is possible to find a balance between the two May allow better performance and correctness tracing Scheduler Activations N:M model for mapping user threads to kernel threads User-level control via kernel-user cooperation Lottery Randomized proportional scheduling Fair in the long-term, but short-term behavior is unpredictable EECS 582 – F16
Reliability and Fault Tolerance EECS 582 – F16
Reliability and Fault Tolerance Nooks Failure is inevitable Isolate it and start again Command logging and recreate the state transparently instead of restarting RaceTrack Detects data races using locksets and happens-before relationship Warning during runtime and code-segment correlation post facto Adaptive granularity: split memory into chunks for fine-grained analysis when they suspect race in the larger chunk EECS 582 – F16
Virtual Machines EECS 582 – F16
Virtual Machines Xen and ESX Arrakis Virtualization comes in many shapes and forms (e.g., full virtualization vs paravirtualization) Choose the one that fits your requirements (e.g., performance, consolidation, deployability, nesting!) Fit for your workload Arrakis Hardware-supported I/O virtualization enables efficient separation of control and data planes Borrows from Exokernel; requires app changes and hardware support Multiplexing across mutually untrusting applications (again w/ hw support) EECS 582 – F16