Prescheduling Consumer Threads for Low-Latency CPU Task Transfer

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In multiprocessor systems, especially in low-end embedded devices, there is a significant delay in transferring tasks between CPUs due to scheduling latency, leading to performance degradation, as interrupts are often handled by a primary CPU, causing overutilization and underutilization of CPUs.

Innovation Solution

Prescheduling an alternative CPU as soon as a need for a task is detected by the primary CPU, by sending an event to wake up the consumer thread and stalling it in a non-pre-emptible spinlock until the task is published, allowing parallel execution and minimizing delays.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of time

If a producer thread creates a task and waits for a consumer thread to execute it, then the task can be transferred between CPUs, but there is a significant delay due to scheduling latency in waking up and preparing the consumer thread

Engineering Contradiction:
Improvedelay in task transferVSAvoidtask execution speed
Core Design Contradiction:
Loss of timeVSProductivity

Solution Approach 1:

The consumer thread is activated and prepared in advance before the actual task is ready for execution. The thread is put into a waiting state at a predetermined memory location, so when the producer thread publishes the task, the consumer thread is already positioned and can immediately retrieve and execute it, eliminating scheduling latency.

Inventive Principle:
Principle #10Preliminary action

2Productivity

If the consumer thread is activated early to reduce delay, then task transfer speed improves, but the thread may waste time waiting idle before the task is ready

Engineering Contradiction:
Improvetask transfer speedVSAvoididle thread consumption
Core Design Contradiction:
ProductivityVSLoss of energy

Solution Approach 1:

The consumer thread autonomously monitors a predetermined memory location for task publication without requiring external scheduling or waking. This self-service mechanism allows the thread to remain dormant until needed, then immediately become active when the producer publishes a task, minimizing both delay and idle time.

Inventive Principle:
Principle #25Self-service

3Device complexity

If interrupts are handled exclusively on a primary CPU, then the system architecture is simpler, but the primary CPU becomes overutilized and unavailable for other tasks

Engineering Contradiction:
Improveinterrupt handling architectureVSAvoidCPU availability
Core Design Contradiction:
Device complexityVSProductivity

Solution Approach 1:

The interrupt handling function is extracted from the primary CPU and redirected to alternative CPUs. When an interrupt occurs, the system can publish the corresponding task to a consumer thread running on a different CPU, distributing the processing load and preventing overutilization of the primary CPU while maintaining architectural simplicity.

Inventive Principle:
Principle #2Taking out (Extraction)

Data Source

PatentEP3436944B1Fast transfer of workload between multiple processors
Publication Date: 2021.09.08 MICROSOFT TECHNOLOGY LICENSING LLC
  • EP3436944B1 patent drawingFigure 1
  • EP3436944B1 patent drawingFigure 2

AI summary

Techniques and systems for prescheduling an alternative CPU as soon as a need for a task is detected by a primary CPU are disclosed. A process includes detecting, by a producer thread running on a first CPU, an external interrupt, acquiring, by the producer thread, a spinlock, and in response to acquiring the spinlock, sending, by the producer thread, an event to a consumer thread that is to run on a second CPU. Upon receiving the event by the consumer thread, the consumer thread acquires the spinlock, which "stalls" the consumer thread in a loop until the spinlock is released by the producer thread. While the consumer thread is "waking up" in response to receiving the event from the producer thread, the producer thread creates a task, publishes the task, and releases the spinlock, thereby causing the consumer thread to exit the loop, retrieve the task, and execute the task.