Linux dionisys a kernel based approach to qos management
This presentation is the property of its rightful owner.
Sponsored Links
1 / 18

Linux Dionisys: A Kernel-Based Approach to QoS Management PowerPoint PPT Presentation


  • 47 Views
  • Uploaded on
  • Presentation posted in: General

Linux Dionisys: A Kernel-Based Approach to QoS Management. Richard West & Jason Gloudon Operating Systems & Services Group. Motivation. General purpose systems have limitations: Ill-equipped to meet service requirements of complex real-time applications Aim to extend COTS systems to:

Download Presentation

Linux Dionisys: A Kernel-Based Approach to QoS Management

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Linux dionisys a kernel based approach to qos management

Linux Dionisys: A Kernel-Based Approach to QoS Management

Richard West & Jason Gloudon

Operating Systems & Services Group


Motivation

Motivation

  • General purpose systems have limitations:

    • Ill-equipped to meet service requirements of complex real-time applications

  • Aim to extend COTS systems to:

    • better meet the service needs of applications

    • provide finer-grained service management than at user-level

    • adapt system behavior to compensate for changes in resource needs and availability


Approach

Approach

  • Linux Dionisys

    • Distributed system for run-time service adaptation

    • Allow real-time applications to specify:

      • how, when & where actual service should be adapted to meet required / improved QoS

    • MEDEA: Mechanism for Event DrivEn Adaptation

    • SafeX: Safe kernel eXtensions


Example system usage

Example System Usage

  • Scalable web servers / farms

    • Adaptive load-balancing, caching

  • Adaptable protocols

    • For flow, error, rate control etc

  • Coordinated resource management

    • e.g., Tradeoffs in CPU versus bandwidth usage


Linux dionisys components

Linux Dionisys Components

  • Service extensions:

    • Service managers (SMs)

    • Monitors - influence when to adapt

    • Handlers - influence how to adapt

  • MEDEA event channel subsystem

    • Transport events between SMs, where adaptation is needed

  • SafeX daemons

  • Nameserver, library (API)


Linux dionisys overview

Linux Dionisys Overview

Lookup / Translation

App process

App process

Daemon

Daemon

Daemon

Nameserver

RPCs

RPCs

Host 1

Host n

Dionisys

Library

Dionisys

Library

User

Level

Kernel

Level

SM 3

SM 1

(eg., CPU)

SM m

(eg., Buffer)

SM 2

(eg., Network)

Event Channels


Medea

MEDEA

  • Provides “event-channels” for communication

    • One source (a monitor)

    • Potentially many destinations (handlers)

    • Events are asynchronous but may be cascaded

  • Provides cross-host, cross-address-space & cross-protection-domain communication

    • e.g., kernel upcalls

  • Uses “mailbox” abstractions:

    • One outbox for every monitor

    • One inbox for every service manager


Decoupled management delivery

Decoupled Management & Delivery

  • MEDEA provides an API for unrestricted event-driven communication

Event

Mailboxes

Monitors

Event

Dispatcher &

Receiver

Service Manager

Handlers


Medea features

MEDEA Features

  • Can batch or select single events for delivery

    • Supports “fast” syscalls that do not block &

      real-time upcalls

    • Coordinated user-level event delivery and handling

  • Prioritized event delivery

    • Can dispatch (receive) events from (into) mailboxes according to an ordering policy

    • Real-time event delivery is possible


Safex

SafeX

  • Allows app-specific service extensions to be dynamically-linked into kernel address space

    • Can deploy code on remote hosts

  • Provides compile- and run-time support to:

    • Enforce bounded execution of extensions

    • Guarantee service isolation (using “guard” fns)

    • Maintain system integrity


Safex features

SafeX Features

  • Extensions written in Popcorn & compiled into Typed Assembly Language (TAL)

  • Memory protection:

    • Prevents forging pointers to arbitrary addresses

    • Prevents de-allocation of memory until safe

  • CPU protection:

    • Requires resource reservation for extensions

    • Aborts extensions exceeding reservations

  • Interfaces to synchronization objects


A kernel service manager

A Kernel Service Manager

Kernel timer queue of bottom half (SM) functions

get_attributes()

Kernel policy-specific structures

Class 1

Events out

Monitors

Class 2

Attribute Classes

Handlers

Events in

Class k

set_attributes()

Guard fn

Kernel Service Manager


Experimental scenario

Experimental Scenario

  • CPU service manager monitors CPU utilization and adapts process timeslices

    • Timeslices adjusted by PID function of target & actual CPU usage

    • Monitoring performed every 10mS

  • Kernel monitoring functions invoked via timer queue

  • User-level approach periodically reads /proc/pid/stat

    • Adapts service via kill() syscalls


Monitors and handlers

Monitors and Handlers

void monitor () {

actual_cpu = get_attribute (“actual_cpu”);

target_cpu = get_attribute (“target_cpu”);

raise_event (“Error”, target_cpu - actual_cpu);

}

void handler () {

e[n] = ev.value; // nth sampled error

/* Update timeslice adjustment by PID fn of error */

u[n] = (Kp+Kd+Ki).e[n] - Kd.e[n-1] + u[n-1];

set_attribute (“timeslice-adjustment”, u[n]);

}


Guard functions

Guard Functions

// Check the QoS safe updates to a process’ timeslice

default_timeslice = target_cpu;

guard (attribute, value):

if (attribute == “timeslice-adjustment”)

if (value in range [0, 0.25*default_timeslice])

if (value is QoS safe)

timeslice = target_cpu + value;


Cpu service management 1

CPU Service Management -1

45

45

40

40

35

35

30

30

25

25

% of CPU

% of CPU

20

20

15

15

10

10

5

5

0

0

0

10

20

30

40

50

60

70

80

90

100

0

10

20

30

40

50

60

70

80

90

100

time (seconds)

time (seconds)

  • 3 CPU-bound tasks w/ 30, 20 & 10% target CPU shares

  • Less service oscillation in left graph for kernel service management

  • Transient overloads do not affect service guarantees


Cpu service management 2

CPU Service Management -2

45

45

40

40

35

35

30

30

25

25

% of CPU

% of CPU

20

20

15

15

10

10

5

5

0

0

0

10

20

30

40

50

60

70

80

90

100

0

10

20

30

40

50

60

70

80

90

100

time (seconds)

time (seconds)

  • 3 MPEG processes with 40, 30 & 20% target CPU shares

  • Finer-grained kernel service management is capable of sustaining 20% CPU utilization for 3rd process (left graph)

  • User-level management (right graph) cannot meet needs of process with target 20% CPU utilization


Conclusions

Conclusions

  • Linux Dionisys supports service extensions to customize system for app-specific needs

  • SafeX verifies safety of extensions

    • Extensions may be dynamically-linked into local & remote address spaces

  • MEDEA provides event-based communication mechanism that triggers service adaptations

  • Overall system improves service to applications


  • Login