Utility-Function based Resource Allocation for Adaptable Applications in Dynamic, Distributed Real-Time Systems

1. Utility-Function based Resource Allocation for Adaptable Applications in Dynamic, Distributed Real-Time Systems Presenter: David Fleeman { fleeman@ohio.edu } F. Drews, L. Welch, D. Juedes and D. Fleeman Center for Intelligent, Distributed & Dependable Systems Ohio University Athens, OH WPDRTS 2004 April 26, 2004

2. Overview • Simplistic model for resource (re)-allocation algorithms. • Formalization of a multi-criterion optimization problem. • Service Attributes • Extrinsic Attributes • Simple hierarchical architecture that supports the algorithm. • How it would fit into the QARMA architecture. WPDRTS, April 26, 2004

3. Common real-time engineering approaches • Use “worst-case” execution times to characterize workloads a priori. • Allocate computing and network resources to processes at design time. Problems: • Limits the functionality and flexibility of applications to adapt to new situations. • Limits the options to handle overloading of system resources. • May lead to poor resource utilization. • Inappropriate for applications that must execute in highly dynamic environments. WPDRTS, April 26, 2004

4. How to react in response toenvironmental changes? 1. Reallocation approach • Dynamically reconfiguring the way in which computing and network resources are allocated to processes 2. Service level and utility approach • Simple strategy: assigning fewer resources by slowing applications down (first few versions of BBN UAV OEP). • More advanced strategy: utility function and service levels WPDRTS, April 26, 2004

5. Service levels and Utility function Approach Utility function: • Defined as the “user perceived benefit by performing a certain action with a particular fidelity within the given time constraints”. • Function that describes the quality of the output of an application depending on the service level. • Specified by the user. WPDRTS, April 26, 2004

6. Our approach • Most existing approaches are based on either reallocation of resources or adaptation of service levels in response to dynamic changes in the environment without a notion of system utility. • Our approach combines the dynamic reallocation and the service level with the goal of optimizing system utility. • Similar work • Q-RAM from CMU • Dr. Jensen’s work in TUF and UA WPDRTS, April 26, 2004

7. Definition of the System Model Hardware components • Set of hosts: Each host specified by • memory size, SPEC rates, etc. • Interconnection Network WPDRTS, April 26, 2004

8. Definition of the System Model Software components: Application software system: • Logical view that distinguishes several layers of abstraction: • Highest level: Total system • Next lower level: Collection of subsystems • A subsystem is a collection of paths, each with a given period or maximum event-rate • Path consists of a set of tasks (or applications) and data-depedencies between tasks WPDRTS, April 26, 2004

9. Definition of the System Model Software components Set of tasks: Each task specified by • execution time profiles and memory profiles: • depending on the processor is assigned to • depending on certain operational conditions set by the environment (“extrinsic attributes”) • depending on certain parameters that can be changed at runtime (“ service level attributes”) • periodic applications: period • event-driven applications: maximum event rate modelled by WPDRTS, April 26, 2004

10. Definition of Extrinsic Attributes • Express functional conditions or requirements • Determined by environmental conditions • Determined by status of system components. • Set by external conditions and cannot be changed by the system • Examples: • event-rate of event-driven tasks • workload WPDRTS, April 26, 2004

11. Definition of Service Attributes • Can be changed at any time by resource manager • If external conditions change, appropriate settings of the service attributes allow adaptation to the new conditions • Examples: • Compression algorithm or type • Pixel processing parameters WPDRTS, April 26, 2004

12. Utility Functions For local optimization, each subsystem is provided a local utility function that measures the contribution of subsystem to the overall system utility • represents the maximum manageable extrinsic attibutes The (overall) system utility function can be computed from the subsystem utilities by means of some aggregation function: Example: WPDRTS, April 26, 2004

13. Optimization Objective Find an allocation of applications to hosts and settings of service attributes and settings of maximum manageable extrinsic attributes such that • The allocation is feasible (i.e., runtime conditions and memory limitations on the hosts are satisfied. That is, all the applications meet their deadlines) • The overall system utility is maximum • The values of the maximum manageable extrinsic attributes are as high as possible WPDRTS, April 26, 2004

14. Service Table Ideas: • Using a table look-up technique for the resource manager. • Restrict the problem to discrete grid points. • RM is provided with a table containing “good candidate solutions”,i.e., allocations along with service attribute settings and (maximum) manageable extrinsic attributes that are computed during a pre-runtime analysis. • Service table: WPDRTS, April 26, 2004

15. Simple Example 6 5 4 3 2 1 1 2 3 4 5 6 WPDRTS, April 26, 2004

16. Hierarchical Architecture of anAdaptive Resource Manager Main Objectives: • Reflect the logical decomposition into subsystems, paths, and applications • Scalability: Remove or reduce the bottleneck of a central resource manager Main Assumption: • Task migration is more expensive than modification of service level parameters WPDRTS, April 26, 2004

17. HierarchicalArchitecture of anAdaptive Resource Manager Dynamic Reallocation Chooses allocation from ST Overall System Utility Optimization Receive sub-table from AM Local Utility Optimization by means of Service Level Modification WPDRTS, April 26, 2004

18. Generic Resource Management Architecture Configuration Files Detectors Decision-Maker Monitors Information Repository Enactors Environment Resource Instrumentation Software Instrumentation Resource and Software Management Commands Computing Environment & User Applications WPDRTS, April 26, 2004

19. CORBA Resource Management Architecture Resource Management Architecture QARMA Components Specification Tool Configuration Files System Repository Service Resource Management Service Enactor Service Replaceable Components Host and Network Monitor / Detector Software Performance Monitor / Detector Enactor (Quality Connector) Hosts/Networks Host and Network Monitor / Detector Software Performance Monitor / Detector Enactor (Quality Connector) Host and Network Monitor / Detector Software Performance Monitor / Detector Enactor (Quality Connector) Resource Management Service Goal • Each chain of applications achieves a “benefit” based on it’s service attribute settings (e.g., frame rate) and extrinsic attribute settings (e.g., importance). • The Resource Management Service changes service attributes in order to optimize total benefit, subject to the constraint that all tasks meet their real-time requirements. UAV Video ATR Tracking Application Layer (independent of QoS mechanism) WPDRTS, April 26, 2004

20. Integration of Approach in QARMA Resource Management Architecture QARMA Components Specification Tool Configuration Files System Repository Service Allocation Manager Enactor Service Replaceable Components Global Service Optimizer Host and Network Monitor / Detector Enactor (Quality Connector) Hosts/Networks Host and Network Monitor / Detector Enactor (Quality Connector) Host and Network Monitor / Detector Enactor (Quality Connector) Local Service Optimizer 1 Local Service Optimizer 1 Local Service Optimizer 1 UAV Video ATR Tracking Application Layer (independent of QoS mechanism) WPDRTS, April 26, 2004

21. Contribution of this paper • Lays the basis for further work on online and offline resource allocation algorithms. • Provides a general optimization model and an architecture for dynamic, distributed real-time systems. • Introduces hierarchical decision-making architecture. • Shows how it can (will) be implemented in a real resource management system. WPDRTS, April 26, 2004