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

It Works!

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

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 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)

Network Service ArchitectureOngoing 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’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

Thanks!

Acknowledgments

• Research supported by – Microsoft (Award #024263)– Intel (Award #024894)– U.C. Discovery funding (Award #DIG07-102270)

• Additional support from Par Lab affiliates– National Instruments, NEC, Nokia, NVIDIA, Samsung, and

Sun Microsystems.