Post on 31-Dec-2015
A Real-Time, Parallel GUI Servicein 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
Sneak Peek at Data
TraditionalGUI 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
Spac
e
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– 1st-level scheduler (Kernel)– 2nd-level scheduler (User)
2nd-level Scheduling
2nd-level Mem Mgmt
App 1 App 2
Cell ATask
Time
Spac
e
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
VFB
SRM
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 EstablishmentOngoing 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 ServiceVisual App(Best Effort)
User ActionUser ActionProbe Request
User ActionProbe Request
CPU Time inGUI Service
SLAAcceptVisual App(Real-Time)
Related Work
1. John E. Sasinowski and Jay K. Strosnider. ARTIFACT: A platform evaluating real-time window system designs. In Proc. of RTSS’952. Norman Feske and Hermann Hartig. DOpE – a window server for real-time and embedded systems. Technical Report TUD FI033. Nicola Mainca et al. QoS support in X11 window system. Proc. Of RTAS’08
Service Time Guarantees
Performance Isolation Parallelism
ARTIFACT1
DOpE2
QoS X113
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