Task Scheduling State Model for Latency Reduction

Resolve Bottlenecks,
Find Innovative Solutions
Generate 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

VSEngineering 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

Engineering Contradiction:
Improvescheduler complexityVSAvoidtask execution latency
Core Design Contradiction:
Device complexityVSLoss of time

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.

Inventive Principle:
Principle #10Preliminary action

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.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Productivity

If execution time prediction is implemented, then task scheduling efficiency improves, but the system requires additional data collection and processing mechanisms

Engineering Contradiction:
Improvetask scheduling efficiencyVSAvoidsystem complexity
Core Design Contradiction:
ProductivityVSDevice complexity

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.

Inventive Principle:
Principle #25Self-service

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.

Inventive Principle:
Principle #35Parameter changes

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

Engineering Contradiction:
ImproveCPU distribution fairnessVSAvoidtask processing throughput
Core Design Contradiction:
ReliabilityVSProductivity

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.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS8250579B2Method for stage-based cost analysis for task scheduling
Publication Date: 2012.08.21 ORACLE AMERICAN INC
  • US8250579B2 patent drawing
  • US8250579B2 patent drawing
  • US8250579B2 patent drawing

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.