Task Scheduling State Model for Latency Reduction
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current task schedulers in computing environments face challenges in predicting the execution time of tasks, leading to inefficiencies and potential latency issues, especially in environments where tasks cannot be time-sliced, such as in single-processor systems or latency-sensitive applications like MMORPGs.
Innovation Solution
A state model is created to estimate the execution time of tasks based on past performance data, tracking states and transitions to predict the CPU requirements and order of tasks, allowing the scheduler to prioritize tasks without requiring runtime information from applications.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Device complexity
If tasks are scheduled without execution time prediction, then the scheduler is simple to implement, but task execution latency increases and CPU distribution becomes inefficient
Solution Approach 1:
The system performs preliminary action by collecting execution time data for each task signature during runtime and storing it in a data structure before scheduling decisions are made. This pre-collected information enables the scheduler to make informed decisions without adding complex prediction algorithms, thus reducing latency while maintaining scheduler simplicity.
Solution Approach 2:
An intermediary data structure is introduced to store execution time information associated with task signatures. This intermediary component bridges the gap between task execution and scheduling decisions, providing the scheduler with historical performance data without requiring the scheduler itself to be complex or to implement prediction algorithms.
2Productivity
If execution time prediction is implemented, then task scheduling efficiency improves, but the system requires additional data collection and processing mechanisms
Solution Approach 1:
The system implements self-service by automatically collecting execution time data during normal task execution and populating the data structure without requiring external intervention or complex monitoring infrastructure. The tasks themselves generate the data needed for scheduling optimization through their normal execution patterns.
Solution Approach 2:
The system changes parameters by utilizing existing task signature identifiers and associating them with execution time metrics. Rather than introducing new complex parameters or algorithms, the approach leverages existing task identification mechanisms and augments them with performance data, simplifying the overall system architecture.
3Reliability
If time-slicing is used to maintain fairness, then CPU distribution among applications is balanced, but tasks that cannot be time-sliced experience delays and application freezing
Solution Approach 1:
The system applies dynamics by making scheduling decisions adaptive based on historical execution time data. Rather than using static time-slicing intervals, the scheduler dynamically adjusts task scheduling based on learned performance patterns, allowing tasks that cannot be time-sliced to receive appropriate CPU allocation without causing application freezing while maintaining fairness for other tasks.
Data Source
AI summary
One embodiment may estimate the processing time of tasks requested by an application by maintaining a state-model for the application. The state model may include states that represent the tasks requested by the application, with each state including the average run-time of each task. In another embodiment, a state model may estimate which task is likely to be requested for processing after the current task is completed by providing edges in the state model connecting the states. Each edge in the state model may track the number of times the application transitions from one task to the next. Over time, data may be gathered representing the percentage of time that each edge is from a state node. Given this information, the scheduler may estimate the CPU cost of the next task based on the current state, the most likely transition, and the cost of the predicted next task. The state model may also track multiple users of the application and modify or create the state model as the users traverse through the state model.


