A Real-Time, Parallel GUI Service in Tesselation OS Albert Kim, Juan A. Colmenares, Hilfi Alkaff, and John Kubiatowicz Par Lab, UC Berkeley

Motivation: Responsiveness Screen freezes because the GUI system has been swapped out Browser’s GUI might disappear when compiling Impossible for me to watch a video while running a simulation We’re going to show how to fix this

Overview Definition of GUI Service: – Render graphics – Handle image/video processing tasks – Window management Want some desired features over basic definition Operate on user-meaningful “actions” – E.g. “draw frame”, “move window” Service time guarantees (soft real-time) – Differentiated service per application – E.g. text editor vs video Performance isolation from other applications Reduce overall service time via task parallelism

Overall Model GUI Service is performance-isolated entity Graphics rendering can be offloaded Can take a global view of GUI actions Acts as front-end to the framebuffer and input devices Draw Frame

It Works!

Sneak Peek at Data Traditional GUI System GUI Service (1 core) GUI Service (4 cores) Out of 4000 frames

Service Time Guarantees for User Actions User actions have deadlines (real-time) Use CPU reservation to allocate CPU time for each application – Each application may request different amounts of CPU reservation Guaranteed CPU time No denial-of-service Custom scheduler that combines: – Global Earliest Deadline First (GEDF) – Multiprocessor Aperiodic Server (MAS) Action 1Action 2Action 1Action 3 CPU Time in GUI Service

Achieving Performance Isolation GUI Service should not conflict with other apps Take advantage of Tessellation OS Tessellation’s goals: – Support a varied mix of applications – Enable applications to deliver guaranteed/consistent performance – Even in scenarios in which applications have conflicting requirements Basic Idea: Tessellation partitions resources (e.g. cores, cache partitions) Time Space

Performance Isolation (continued) Cell: the basic partitioning abstraction – Full control over resources it owns – Encapsulates entire runtime system – Has its own scheduler and memory management system – Efficient inter-cell communication using channels Space-time partitioning – Resources for cells are gang-scheduled – No uncontrolled virtualization Two-level scheduling – 1 st -level scheduler (Kernel) – 2 nd -level scheduler (User) 2nd-level Scheduling 2nd-level Mem Mgmt App 1App 2 Cell A Task Time Space Cell B Channel

Parallelism Rendering is CPU-intensive, so parallelize Not a problem for non-overlapping windows Even for overlapping, we can use virtual framebuffers (VFB) – Render to virtual framebuffer, then use screen region map (SRM) when flushing to the real framebuffer It gets tricky with window management VFB SRM

GUI Service Architecture

Experiment Setup Capture end-to-end service times (less is better) 8 video clients, each sending 4000 video frame requests – 4 are 30-fps videos (352 x 288) – 4 are 60-fps videos (352 x 288) 5 different GUI system setups – Traditional window system running on Linux (Nano-X/Linux) – Traditional window system running on Tessellation (Nano-X/Tess) – GUI Service running on Tessellation With 1 core (GuiServ(1)/Tess) With 2 cores (GuiServ(2)/Tess) With 4 cores (GuiServ(4)/Tess) Running on machine with 8 hyperthreads Window system and video clients running on separate cores

Experimental Data Nano-X/ Linux Nano-X/ Tess GuiServ(1)/ Tess GuiServ(2)/ Tess GuiServ(4)/ Tess Out of 4000 frames

Service Level Agreement Establishment Ongoing Work Right now, we have to manually profile applications to figure out how much CPU time they require from the GUI Service – Painful and takes a lot of effort – Reason why people don’t like doing real-time We can profile applications on-the-fly GUI Service Visual App (Best Effort) User Action Probe Request User Action Probe Request CPU Time in GUI Service SLA Accept Visual App (Real-Time)

Network Service Architecture Ongoing Work Network Interface Card

Related Work 1.John E. Sasinowski and Jay K. Strosnider. ARTIFACT: A platform evaluating real-time window system designs. In Proc. of RTSS’95 2.Norman Feske and Hermann Hartig. DOpE – a window server for real-time and embedded systems. Technical Report TUD FI03 3.Nicola Mainca et al. QoS support in X11 window system. Proc. Of RTAS’08 Service Time Guarantees Performance Isolation Parallelism ARTIFACT 1 DOpE 2 QoS X11 3 GUI Service

Final Remarks GUI Service meets time requirements of clients in situations in which traditional window systems fail to do so GUI Service meets these requirements by leveraging: – Service time guarantees using real-time schedulers – Performance isolation using Tessellation – Task-level parallelism GUI Service architecture provides an overall pattern for other QoS-aware services

Thanks!

Acknowledgments Research supported by – Microsoft (Award #024263) – Intel (Award #024894) – U.C. Discovery funding (Award #DIG ) Additional support from Par Lab affiliates – National Instruments, NEC, Nokia, NVIDIA, Samsung, and Sun Microsystems.